Document ability to add organizational metadata and complying with SCuBA policy checks via configuration file

[buidav]

🗣 Description

• Updates the SCuBA configuration file documentation to note ability to add additional fields.
• Add a sample config file for those additional fields along with fields needed for complete SCuBA baseline compliance.
• Refactor the documentation for better clarity

💭 Motivation and context

Closes #1425

🧪 Testing

• Ran Invoke-SCuBA -ConfigFilePath scuba_compliance.yaml to see if current config file is valid.

✅ Pre-approval checklist

• This PR has an informative and human-readable title.
• PR targets the correct parent branch (e.g., main or release-name) for merge.
• Changes are limited to a single goal (1.5 goals in this case) - eschew scope creep!
• Changes are sized such that they do not touch excessive number of files.
• All future TODOs are captured in issues, which are referenced in code comments.
• These code changes follow the ScubaGear content style guide.
• Related issues these changes resolve are linked preferably via closing keywords.
• All relevant type-of-change labels added.
• All relevant project fields are set.
• All relevant repo and/or project documentation updated to reflect these changes.
• All relevant functional tests passed.
• All automated checks (e.g., linting, static analysis, unit/smoke tests) passed.

✅ Pre-merge checklist

• PR passed smoke test check.

• Feature branch has been rebased against changes from parent branch, as needed

  Use Rebase branch button below or use this reference to rebase from the command line.

• Resolved all merge conflicts on branch

• Notified merge coordinator that PR is ready for merge via comment mention

• Demonstrate changes to the team for questions and comments.
  (Note: Only required for issues of size Medium or larger)

✅ Post-merge checklist

• Feature branch deleted after merge to clean up repository.
• Verified that all checks pass on parent branch (e.g., main or release-name) after merge.

[schrolla]

I had a number of suggestions for tweaks to the documentation and/or configuration. See below.

[james-garriss]

Is there a schema for these config files? What stops organizations from populating them with whatever fields they want? Or to ask this question a different way, why do we need to create a sample that specifically uses OrgName and OrgUnitName? Or to ask yet another way, what would happen if they used OrganizationName and OrganizationUnit (or whatever fields they made up) instead of these?

[james-garriss]

A few things to adjust or at least to have a conversation about.

[james-garriss]

It looks ready. TY for responding to all my requests for info.