Investigate the usages of SpanContext.create with invalid ids, but useful flags and trace state.

[jkwatson]

When implementing #2728 , we uncovered a strange use of the SpanContext.create where tests were passing in invalid span/trace ids, but useful trace flags and trace state. This may just be a testing usage at the moment, but before removing it, we need to research whether it is a valid use-case, or just a testing shortcut.

The outcome of this story should either be
a) document this use and why, potentially adding an additional creational method to support it
b) remove this usage from the tests and make the SpanContext.create return a fully INVALID SpanContext if the span id and trace id are both invalid.

[Oberon00]

I can say that we use this at Dynatrace where we have a custom extractor that works over channels that only allow for annotation of messages with a few bytes (not enough for full trace + span ID). In these cases, we extract a trace+span ID of zero but a trace state with this shorter ID.

There is a corresponding spec issue: open-telemetry/opentelemetry-specification#753

To make this actually useful, we have a patch applied to the SDK span builder to not discard parents with invalid trace and/or span ID but to still use every bit (trace ID only, span ID only, tracestate, trace flags) that is valid in the parent.

[jkwatson]

So, it sounds like there definitely is a use-case for this. I think we should just document that if you pass in invalid trace id or span id, that they'll be replaced with purely invalid (i.e. all 0s) ids. I think that will make clear what we do today and preserve the current behavior.

If, in the future, we need a way to request that you get a different result (i.e. not only all zeroes, but the pure getInvalid() version, we can add a method to support that use-case.

Sound ok?