Implement collection marshaller spec

[jkoritzinsky]

Implement the spec in SpanMarshallers.md for collections.

Move arrays over to using the collection marshallers internally.

Refactor attribute inspection to more easily support holistic analysis of marshalling attributes (see what's used, what isn't, and what provides conflicting info).

This PR does not add built-in support for marshalling spans. That's planned for a future PR (though the implementation will likely follow the ArrayMarshaller in Ancillary.Interop very closely).

[AaronRobinsonMSFT]

Overall, I like this a lot more. I am struggling to reconcile the nested collection logic's cost with the user benefit. I am thinking of the servicing burden of owning such a complex piece of logic for the very few users in practice. I wonder if there is some way we could excise that logic and ensure we have the capability for users do to it themselves if it becomes interesting.

[jkoritzinsky]

This PR doesn't have any of the work to support nested collections. That's in a separate local branch I haven't pushed up. This PR just has the support for the collections spec as written. It doesn't support collection elements with complex marshallers (marshallers with a Value property). That's also later work.

[jkoritzinsky]

Well, it does have support for the ElementIndirectionLevel validation, which is a prereq to nested collections support.

[jkoritzinsky]

If we wanted to, we could just block any ElementIndirectionLevel values above 1. Though we'd still need the same validation for levels 0 and 1, so it wouldn't necessarily be much simpler.

[AaronRobinsonMSFT]

Well, it does have support for the ElementIndirectionLevel validation, which is a prereq to nested collections support.

Yes, that is the logic I was referring to.

If we wanted to, we could just block any ElementIndirectionLevel values above 1. Though we'd still need the same validation for levels 0 and 1, so it wouldn't necessarily be much simpler.

Okay.

[AaronRobinsonMSFT]

LGTM.