Clarify broadcast of complex context types

[kriswest]

Resolves #434
Adds advice to the spec and documentation about how to broadcast complex context types, where other apps on the channel may wish to/are set up to process simpler types that are the fields of your context type. The consensus from #452 was to broadcast each type you want others to respond to separately.
E.g. when broadcasting an fdc3.position, which has an fdc3.instrument field, broadcast instrument and then position.

[mattjamieson]

I still think we can do better on this, perhaps by providing a mechanism for developers to register context adapters to extract the simple types from the composite type. Though maybe that's an opportunity for vendor platform differentiation. 😁

[kriswest]

@mattjamieson I added some example code for that to the issue (#434), which could go into methods.ts. However, if we're recommending/specifying that each type should be broadcast (rapid-fire) then I think it difficult to mix that with a feature to auto-extract types, as combining the two will lead to the same context being received multiple times in rapid succession (and perhaps some flickering?). That could also be dealt with in the implementation (don't redeliver an identical context in a short timespan), but that puts doing so firmly into a specific implementation, rather than the spec

[mattjamieson]

[...] but that puts doing so firmly into a specific implementation, rather than the spec

Yes, I agree, I think decisions on this stay in implementation-land for now while we see how usage develops.