Change dashboard to send telemetry directly rather than via the IDE protocol server

The aspire dashboard currently sends product usage telemetry by "piggy-backing" on the telemetry endpoint provided by the IDE protocol server, i.e. if the dashboard is launched in the context of Visual Studio the IDE protocol server implementation in VS provides an endpoint that the dashboard sends its telemetry to, which is in turn sent out via the VS telemetry pipeline.

We did this initially to avoid the cost of having to onboard the aspire dashboard as a discrete product in the telemetry system we use, but we've since done the work for this for the `aspire` CLI so it's time to let the dashboard handle egressing its own telemetry. The other advantage is we don't need to maintain separate implementations of the telemetry relay service in the various hosts that implement the IDE protocol (VS, VS Code C# extension, VS Code Aspire extension).

We should make this change such that in a given version (e.g. 13.5) the dashboard can now send its own telemetry, but it's done in such a way that it's coordinated with the IDE protocol host so we don't duplicate the telemetry being sent. It's also important that the launching environment's telemetry opt-out flag is still honored, so e.g. if the user is in VS and they launch an aspire app that launches the dashboard, the dashboard does not send telemetry if they'd opted out of VS telemetry already. That means the launching environment should flow this data to the AppHost so it can in turn be sent to the dashboard. Same goes for the Aspire CLI and VS Code opt-out flags.

The other important thing is that the aspire dashboard *container* should **never** send any usage telemetry (just like today). This likely means that while the dashboard will be wired for telemetry by default (as it is today) it won't send any unless the launching environment indicates that it should (e.g. via an environment variable). Note that the new `aspire dashboard` CLI command *should* send usage telemetry as it's being launched in the context of our developer tool.

One of the other outcomes of this work should be that the telemetry event names that get reported from the dashboard should be consistent no matter which environment it was launched from, i.e. `aspire/dashboard/*`. This makes our backend aggregation and reporting far simpler.

@JamesNK @adamint

No files or tests are named. Start by tracing telemetry flow through the dashboard, AppHost, IDE protocol hosts, and the aspire dashboard CLI, including how launching-environment opt-out state is passed. Done means dashboard telemetry is sent directly without duplication, uses aspire/dashboard/* event names, honors opt-outs, and the dashboard container sends none.

Written by the indexing model from the issue text.