chore: remove static Orleans meter

[Meir017]

closes #9608 by removing the static Orleans meter entirely.

This deletes Orleans.Runtime.Instruments, removes the generated API surface for it, converts transaction statistics to use OrleansInstruments when resolved from DI, and leaves direct-construction compatibility paths on per-instance meters instead of a shared static meter.

Depends on #10199 and #10200 to finish moving the remaining provider-created stream monitors to DI-created meters.

Microsoft Reviewers: Open in CodeFlow

[Meir017]

@ReubenBond I'd like your feedback on the compatibility fallback constructors in this PR.

Right now, after removing the static Instruments.Meter, the existing direct-construction paths fall back to creating a new meter, eg:

: this(dimensions, new Meter("Microsoft.Orleans"))

That feels questionable: it avoids the static meter, but it still creates ad-hoc meters outside IMeterFactory, which is not really aligned with the goal of #9608.

Would you prefer that we make this a breaking cleanup instead and add/require an OrleansInstruments parameter on these constructors so the meter always comes from the DI-created OrleansInstruments instance? In other words, remove the ad-hoc new Meter(...) fallbacks rather than preserving direct-construction compatibility here.

[ReubenBond]

@Meir017 Let's make a compilation break and remove the back-compat ctor

[Meir017]

Applied this in 16cc280a9: removed the stream monitor back-compat constructors which created ad-hoc meters, and updated the default Memory/Generator factories to always pass OrleansInstruments.

The affected projects build locally for net10.0.

[Meir017]

Rebased onto current main and pushed a fix for the broad CI failures: #10199 had already added an internal \DefaultQueueAdapterReceiverMonitor(ReceiverMonitorDimensions, OrleansInstruments), and this PR also added a public constructor with the same signature, causing CS0111 across the build. Removed the duplicate internal constructor in \