Address a targeted set of analyzer warnings

[DaveTryon]

Issue #340 provides a long list of analyzer warnings that were added to prevent a build break. The vast majority of the warnings on this list are extraordinarily pedantic, and some of them actually go against what I would consider best practices. I grabbed a few of the rules that seemed worthwhile and didn't represent a huge impact, and made the appropriate changes. At some point, we may want to officially ignore analyzer warnings that we actively don't want. This PR adds enforcement of the following analyzer warnings:

ID/Link	Description	Comment
IDE0005	Using directive is unnecessary	Cleaned up the using blocks that the compiler says it's not using. I had to tell the test code to generate XML comments to enable this--that seems odd but not-problematic
CA1040	Avoid empty interfaces	We only had one, and it exists for a reason, so I suppressed the warning on that one
CA1508	Avoid dead conditional code	Nobody wants dead code
SA1207	Member attributes should follow the order	OK, this is pedantic but it only changed 1 line of code
SA1633	File should have header	This was probably fixed by #347 but the flag was never enforced
SA1626	Single-line comments should not use documentation style slashes	Another pedantic one, but Visual Studio was whining and the fix was trivial
SA1625	Element documentation should not be copied and pasted	Another pedantic one, but Visual Studio was whining and the fix was trivial

Note: This will probably best be reviewed on a per-commit basis. It will flag the banner about changing the API, but it can be ignored because we're not actually changing any of the API surfaces.

[github-actions]

This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:

• Changing the signature of an existing interface method
• Adding a new method to an existing interface
• Adding a required data member to a class that an existing interface method consumes

Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:

Option 1 - Publish this as a breaking change

1. Update the documentation to show the new functionality
2. Bump the major version in the next release
3. Be sure to highlight the breaking changes in the release notes

Option 2 - Refactor the changes to be non-breaking

1. Review this commit, which adds a new interface in a backward-compatible way
2. Refactor the change to follow this pattern so that existing interfaces are left completely intact
3. Bump the minor version in the next release

[DaveTryon]

/azp run

[DaveTryon]

/azp run

[github-actions]

This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:

• Changing the signature of an existing interface method
• Adding a new method to an existing interface
• Adding a required data member to a class that an existing interface method consumes

Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:

Option 1 - Publish this as a breaking change

1. Update the documentation to show the new functionality
2. Bump the major version in the next release
3. Be sure to highlight the breaking changes in the release notes

Option 2 - Refactor the changes to be non-breaking

1. Review this commit, which adds a new interface in a backward-compatible way
2. Refactor the change to follow this pattern so that existing interfaces are left completely intact
3. Bump the minor version in the next release