TrustEngine refactoring

[Cantor, Scott]

Configuration-wise, what's left here is moving the trust engines and
dependent beans that aren't used for anything else into
relying-party-system.xml (that was the actual justification for this work).

The complication is that we also have to handle the legacy config case.
Rod didn't wire in trust engines because there wasn't any place to wire
them, and we injected them directly into the various actions via the beans
in global-system.xml

I'm not very fluent in the Spring parsing code. I guess what we probably
should do is actually parse the existing trust engine(s) (which I guess
we're doing for metadata anyway?) and build:

org.opensaml.xmlsec.impl.BasicSignatureValidationConfiguration
org.opensaml.security.x509.tls.impl.BasicClientTLSValidationConfiguration

and inject those into the defaultSecurityConfiguration property on
net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolv
er

But I don't know how much we care. We could hardwire the two chaining
engines into the system when we parse legacy and just emit warnings like
with the old security policy stuff.

Anyway, we have to do one of those. It won't work right now if we test
with a legacy RP file.

-- Scott