document rationale of looking at "spanId" parameter

[codefromthecrypt]

Right now, we document "spanId" as what insures mechanisms such as TTL or gaps. This also solves a secondary problem, which is knowing if the sampling key was ever sampled before (ex same as b3 sampled=1). An alternative would be to add another field, or delimited property, to indicate the sampling status of the key. However, this would increase the parsing complexity and the overhead of the header.

I didn't mention aloud, but "spanId" serves the same purpose. The rationale summarizes as

things will break if you don't know the upstream span ID. Instead of adding a separate sampled parameter, which may lead to people not adding spanId and then breaking traces, we leverage "spanId" instead.

Note: we don't yet have a RATIONALE.md so this may imply creating it.