Implement OTEL_EXPORTER env var

[iNikem]

How an end-user can configure instrumentation agent to e.g. send spans to Zipkin and metrics to Prometheus? As of now only one exporter can be configured and some of them do not support metrics at all.

[trask]

Moving this proposal over from #511 (comment):

Instead of a set of short names, we don't really need any short names. How about automatically activating an exporter based on the presence of the endpoint flag, like ota.otlp.endpoint, ota.zipkin.endpoint? Currently we only load one exporter but it'd actually be sort of nice if we could just go ahead and enable all the exporters that users set the endpoint for.

Also, this proposal addresses part of #385:

We currently only support a single exporter jar, so how does someone use jaeger + prometheus?

[trask]

I forgot there were concerns about the proposal above (actually doc'd in meeting notes from July 16!!)

See open-telemetry/opentelemetry-specification#710 for the new proposal

[trask]

Dropping from p1 to p3 to match prioritization of auto-collected metrics

[anuraaga]

If selecting multiple exporters is also the same as this, I might mark it p1. Debugging deployment of OTel is quite hard if not able to enable both otlp and logging exporter at same time

[iNikem]

Run local Collector with logging exporter? :)

[anuraaga]

If it's making it to the collector, it's generally in a pretty good state already :) But logging exporter is the easiest way to see instrumentatoon is working, if some infrastructure issue is causing connection problems to the collector when starting out. Just ran into it yesterday.

[pavolloffay]

I would like to work on this one

[trask]

Adding note, shared with @pavolloffay already, let's solve this via OTEL_EXPORTER env var (I will rename this issue)