Prototype: StructuredAccessControl.anyOf

[josh-newman]

@saeta

I've been looking at HeaderAccessControl for a while, and I still find the testing method strange. As we chatted about before, it's forcing access controls to maintain some authenticator/authorizer separation, but letting the boundary be hidden.

This seems bad because:

• Combinators now duplicate some logic between their run and their check (like how they aggregate individual results in anyOf, etc.).
• I'd like to make access control covariant in the authentication type, because run produces the authentication result so it seems natural (and it'd allow more convenient manipulation in our more complex internal access controls), but the internal-for-testing-only check makes this impossible. This makes the abstraction leaky.
• It forgoes the readability and implementation guidance that StructuredAccessControl provides (by constraining what's possible and naming things nicely).

This PR contains a prototype (not suitable for merging) of how the combinators could be defined on StructuredAccessControls. The Scaladoc makes a claim about why this implementation is ok; I'm happy to discuss. If we can agree on this, I want to remove the generic HeaderAccessControl entirely and move that name to StructuredAccessControl, thus forcing all our access controls to have that nice structure.