Normalize "SBOM" to "Sbom" through most of the code base

[DaveTryon]

As called out in #685, our code is very inconsistent in its usage of "SBOM" and "Sbom". Older files seemed to start with "SBOM", then migrated somewhat toward "Sbom", but we have a bit of a mix. We punted on #685 because of compatibility concerns.

As we've discussed separately, SPDX 3.0 is a breaking change, so we have a window of opportunity to standardize our API. This PR is an attempt to name that happen, following the following rules:

1. The new standard is to follow PascalCasing
2. File names and class names are case-consistent
3. Let Visual Studio automate as many of the changes as possible
4. Make the commits as tightly scoped as possible
5. Try to keep the docs in sync with the code changes
6. To keep things clean, use "Sbom" in all code constructs, with 2 exceptions to come later:
7. Files that include "SPDX" in the name (minimize merge conflicts with API changes to support SPDX 3.0 #924
8. Leave the test files alone where possible. I think I renamed 1 test file by mistake, but I can back that out if we want
9. Since I'm working on Windows, which ignores case differences, the file renames were a 2-step process:
10. Rename SBOMFoo to SBOMFoo_, allowing Visual Studio to update all usages
11. Rename SBOMFoo_ to SbomFoo, allowing Visual Studio to update all usages
12. Build and run tests frequently along the way to make sure that we don't perpetuate breakage
13. Search for SBOM\w\w using regular expressions as a way to find cases that may have been missed

The PR itself is broad (92 files), but most of the review should be trivial.

Proposed roadmap:

1. Merge API changes to support SPDX 3.0 #924
2. Update this PR to reflect changes from API changes to support SPDX 3.0 #924
3. Merge this PR
4. Decide if we want to normalize "SPDX" to "Spdx". If so, create a similar PR
5. Create a migration document from API 3.x to 4.0 (we need do this even if we choose not to normalize the casing)
6. Normalize casing in test names (doesn't impact the API, could happen after we release the 4.0 API)

[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

[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

[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

[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]

Merge state seems to be messed up. Closing and replacing with #950

[DaveTryon]

/azp run