This PR is an initial implementation of the official tracestate spec (detailed here), which specifies a multi-vendor, vendor-neutral method of propagating trace data between services. The basic format of a tracestate header is vendor1=value1,vendor2=value2,vendor3=value3,....

Key Behaviors:

• When starting a transaction representing an incoming request*, the request's tracestate header is parsed, and Sentry and third-party portions are stored separately on the transaction
• If no Sentry portion is found, or if a transaction is not being started from headers, a new Sentry tracestate value is calculated and stored on the transaction
• Outgoing requests made while the transaction is open contain a tracestate header of the form sentry=sentry_value,vendor1=value1,vendor2=value2 (in other words, wherever the Sentry data was in the incoming list, it's moved to be the first entry)
• Transactions (and errors with attachments** sent while a transaction is open) include data from Sentry's tracestate value in their envelope headers

* Now that there's more than one header, the from_traceparent method mentioned in an older version of our tracing spec (since replaced by from_sentrytrace in the spec, but not the SDK) is deprecated in favor of two new helper functions called from continue_from_headers.
** Error events with attachments just because those are the only ones currently sent in envelopes.

Sentry's tracestate Value:

• The value in the HTTP header is the result of taking data of the form { "trace_id": ... , "release": ... , "environment": ... , "public_key": ... }, base64-encoding it, and stripping off any trailing =. (release and environment reflect the values set in sentry_sdk.init(), and public_key comes from the part of the DSN between the https:// and the @xxx.ingest.sentry.io.)
• The value in the envelope header is that same data, but without any encoding.

Known Limitations:

Compared to the spec, this does not handle:

• Multiple incoming tracestate headers
• Incoming third-party values which are empty (not not-there, but rather empty like the second entry in x=y,,z=w)
• Whitespace in the incoming tracestate header value
• Limiting the length of either the Sentry tracestate value or the overall tracestate header

It also does not consume, create, or propagate traceparent headers. (We continue to use our own similar sentry-trace header.)

Follow-up Tasks

• Decide if we like the new continue_from_headers/helper function model, and update dev docs
• Decide which, if any, of the known limitations listed above are worth fixing
• Update JS SDK to consume incoming tracestate headers and handle third-party tracestate values
• Sort out whether and how to include end-user data