Redesign Attribute encoding/decoding as a service

Time to take a stab at revamping this into a separate service with a new "separate" configuration for mapping between attribute representations.

I don't think we need to necessarily be compatible with the current APIs in either direction, as this hasn't been a major area of third party development, aside from the OIDC equivalents that we can change as needed.

I would like to start with a strawman proposal for doing this with native Spring, probably allowing for compatibility with the resolver as a "legacy" option along the lines of how the RelyingParty support was done, but it may be more practical to come up with a new syntax.

I'm inclined to model more of this on my SP's AttributeDecoder model just because I understand it a lot better than the AttributeMapper code from V3, but I'll see how it goes.

I'm attracted to the idea that we could have more of a symmetric design with each plugin being required to support both directions, i.e. a SAML 2 encoder that supports String values has to also support decoding all SAML 2 constructs back into String IdPAttributeValue objects and so on.