[OpenTracing bridge] Support setting span kind tag after the creation of span

[ChenX1993]

Resolves #3953

A few middleware frameworks (e.g https://github.com/yarpc/yarpc-go/blob/600cb49cc6331d8d15f65c058615a7649447efa7/api/transport/propagation.go#L67) that our company is using still set the OT span kind tag after a span is created.

Missing the span kind tags will impact a few functionalities in Jaeger (one of the OpenTracing implementations) that reply on the span kind tags.

Setting span kind tag in the bridge after a span is created cannot really set the SpanKind of OTel span, but adds the attribute instead which still helps in our case a lot.

[codecov]

Codecov Report

Merging #3997 (b8e066b) into main (1b04bbc) will increase coverage by 0.0%.
The diff coverage is 100.0%.

❗ Current head b8e066b differs from pull request most recent head ad34f57. Consider uploading reports for the commit ad34f57 to get more accurate results

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #3997   +/-   ##
=====================================
  Coverage   82.2%   82.2%           
=====================================
  Files        175     175           
  Lines      13058   12987   -71     
=====================================
- Hits       10738   10681   -57     
+ Misses      2099    2084   -15     
- Partials     221     222    +1     

Impacted Files	Coverage Δ
bridge/opentracing/bridge.go	65.2% <100.0%> (+1.4%)	⬆️
bridge/opentracing/internal/mock.go	73.7% <100.0%> (+6.6%)	⬆️

... and 24 files with indirect coverage changes

[WillSewell]

This will cause the span.kind to be duplicated at the exporter level. This will set it in the attributes, but the recordingSpan.spanKind will also be set to the default internal - both of these seem to get sent via the exporter. I've tested this with go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc sending to Jaeger collector.