Propagators section clean up

[carlosalberto]

In #440 a few issues arose about the overall structure and current content of api-propagators.md:

• We should define, earlier in the documentation, the Carrier interface, and mention it is mutable.
• Add the notion of Format as a representation of the restrictions that a given message transport imposes on the data, and avoid the term formatter.
• Add the notion of "Application Message" that semantically consists of metadata (e.g. HTTP headers) and the payload.
• The Fields section needs to be clearer and not part of the HttpFormat
• Do we really need to separate Carrier and Setter (and maybe Getter)?

[yurishkuro]

add: having only Get in the Getter is incompatible with OpenTracing, e.g. Jaeger's baggage cannot be retrieved via Get because the headers include the user's baggage key, e.g. uberctx-myBaggageKey.

[Oberon00]

Do we really need to separate Carrier and Setter (and maybe Getter)?

We don't need to, but it allows using a singleton object for getter/setter and an already existing object for carrier instead of creating a new combined object just for telemetry. However, I think the carrier should be an optional (i.e. nullable) argument.

[andrewhsu]

Talking with @carlosalberto today, looks like only thing left from the description of this issue is:

• Add the notion of "Application Message" that semantically consists of metadata (e.g. HTTP headers) and the payload.

So bumping this down to P3.