Address Metrics APIs issues

[tarekgh]

The changes here addressing the following issues:

• To ensure the factory owns the meter's lifetime, the factory's created meter should have a no-op disposal operation. [Tracking] Figure out how we should handle the disposing of the meters created from meter factory #86592
• Ignore the order of the tags when caching instruments and meters to make them order insensitive. [Tracking] Decide if the tags order matter when creating meter or instrument #86614
• Remove the scope parameter from the IMeterFactory extension Create method.
• Throw exception when the user calls IMeterFactory passing MeterOptions with non-null scope and not equal to IMeterFactory instance. DefaultMeterFactory.Create and MeterOptions.Scope #86684
• Moved the IMeterFactory Create method from Microsoft.Extensions.Diagnostics to Microsoft.Extensions.Diagnostics.Abstraction library.
• Remove the added dependency on the System.Linq in the system.Diagnostics.DiagnosticSource library.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[stephentoub]

Why is the dependency problematic?

[tarekgh]

The auto-instrumentation can force loading higher version of System.Diagnostics.DiagnosticSource than the version of the one that app built with. Increasing the dependency of System.Diagnostics.DiagnosticSource can increase the risk of breaking the auto-instrumentation. Here is some related issue talking about similar thing #42244

[tarekgh]

#86567
#77514

[noahfalk]

Mostly looked good. I think I spotted two bugs and a few other suggestions inline.