Update env vars in spec compliance matrix

[pellared]

What

• OTEL_SERVICE_NAME is supported by OTel Go: sdk/resource: honor OTEL_SERVICE_NAME in fromEnv resource detector opentelemetry-go#1969
• OTEL_EXPORTER_JAEGER_* are supported by OTel Go: https://github.com/open-telemetry/opentelemetry-go/tree/main/exporters/jaeger
• OTEL_EXPORTER_JAEGER_* are supported by OTel .NET: https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/src/OpenTelemetry.Exporter.Jaeger

PTAL: @Aneurysm9 @MrAlias @cijothomas

[carlosalberto]

@open-telemetry/dotnet-maintainers We need at least one approval from you ;)

[arminru]

As per the docs in
https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/src/OpenTelemetry.Exporter.Jaeger#environment-variables
only 2 out of the 6 env vars defined in
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md#jaeger-exporter
are supported by otel-dotnet.

Should we state the env vars individually so this is clear or otherwise indicate that it's only partially supported?
There might also be more to come which would void the current + indicators again.

[CodeBlanch]

LGTM for .NET support in Jaeger. I do like @arminru's idea to break out the individual vars for clarity + future-proofing.

[pellared]

break out the individual vars for clarity + future-proofing

I think it would be better to be done in a separate PR. Especially that it would need probably a review from all SIG maintainers.

[arminru]

break out the individual vars for clarity + future-proofing

I think it would be better to be done in a separate PR. Especially that it would need probably a review from all SIG maintainers.

@pellared Makes sense 👍