Straw-man for security parameter placement

[Cantor, Scott]

In the interest of moving the missing pieces of the profile handlers
along, I'll suggest we try this approach for handling the security
parameter classes in the context tree. Most of this will be pluggable with
lookup functions anyway.

- Stick with one SecurityParametersContext for all 4 types, and we'll
populate them in particular places based on the policy over whether to
sign/encrypt, which was more or less agreed to.

For SignatureValidationParameters:

- below inbound message context for protocol/binding-level signature
checking
	- populate in a profile action that runs before we end up doing the
dynamic message
	handler chain lookup, which is where the verifying handlers will be

- below RelyingPartyContext for "body" signatures such as assertions
	- this seems fairly profile specific (e.g. maybe we do this the
delegation case where we
	verify our own signed assertions, but in that case we probably are using
a more complex
	RelyingParty scenario such as one for "self")
	- suggest we don't get too caught up with this yet

For SigningParameters:

- below outbound message context for protocol/binding-level signing
- below RelyingPartyContext for assertion signing
	- populate both via a dedicated action that resolves the parameters to use

For DecryptionParameters:

- below RelyingPartyContext
	- populate with a dedicated action that resolves the parameters to use

For EncryptionParameters:

- below RelyingPartyContext for the recipient of the encrypted data
- suggest the action doing encryption actually "resolves" the full set of
RelyingPartyContexts
to whom we encrypt, looks for child contexts below them, and multicasts
the encryption to them
	- populate with dedicated action that resolves the parameters to use
	- this would be where things blow up if we can't resolve a key but we
must encrypt

Let me know if anything jumps out sounding broken there.

-- Scott