Metrics updates

[hananiel]

Description

Adds metrics for clr.cpu.count
Adds an AllowList Option to only add metrics needed, as opposed to listing all unneeded metrics
for example:

 "Metrics":{                                              
   "Observer":{                                 
     "EventCounterEvents": true,                
     "IncludedMetrics": ["cpu-usage"]           
     }                                            
  }                                              

Quality checklist

• Your code complies with our Coding Style.
• You've updated unit and/or integration tests for your change, where applicable.
• You've updated documentation for your change, where applicable.
  If your change affects other repositories, such as Documentation, Samples and/or MainSite, add linked PRs here.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.
• You've added required license files and/or file headers (explaining where the code came from with proper attribution), where code is copied from StackOverflow, a blog, or OSS.

[hananiel]

/azp run Steeltoe.All

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

100.0% Coverage
0.0% Duplication

[TimHess]

looks OK to me, wouldn't be a bad idea to address the sonar issue now but isn't required in this branch

[bart-vmware]

looks OK to me, wouldn't be a bad idea to address the sonar issue now but isn't required in this branch

Just because no warning is produced? In that case, I'm afraid I have to disagree. In that same reasoning, it would be okay to introduce race conditions. Writing proper English is something we should do regardless of tooling.

I don't expect this PR to fix all existing docs, but we should get it right from the start for new ones. There's no point in postponing. The effort is minimal and it needs to be done anyway. Postponing only makes it harder to merge to main at a later time.

[TimHess]

looks OK to me, wouldn't be a bad idea to address the sonar issue now but isn't required in this branch

Just because no warning is produced? In that case, I'm afraid I have to disagree. In that same reasoning, it would be okay to introduce race conditions. Writing proper English is something we should do regardless of tooling.

I don't expect this PR to fix all existing docs, but we should get it right from the start for new ones. There's no point in postponing. The effort is minimal and it needs to be done anyway. Postponing only makes it harder to merge to main at a later time.

I get your point, and in that case my response would be different, but in this particular case we're talking about two periods that probably won't even be noticed by anybody. In the future, for trivial changes like this I think it would be nice to include the suggested change up front (when possible) for a quicker resolution