Reduce cli command complexity

[david-waltermire]

Committer Notes

Refactored CLI commands to simplify the command pathways for conversion, profile resolution, and validations to make these commands more continuous integration (CI) friendly.

The following commands have been simplified:

• oscal-cli (catalog,profile,component-definition,ssp,ap,ar,poam) validate -> oscal-cli validate
• oscal-cli (catalog,profile,component-definition,ssp,ap,ar,poam) convert -> oscal-cli convert
• oscal-cli profile resolve -> oscal-cli resolve

The original commands now output a message indicating that the command pathway has been deprecated, but still work for backwards compatability.

Also improved the ANSI colors and console streams used for output.

This PR depends on #174, which needs to be merged before this PR.

All Submissions:

• Have you selected the correct base branch per Contributing guidance?
• Have you set "Allow edits and access to secrets by maintainers
  "?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you squashed any non-relevant commits and commit messages? [instructions]
• Do all automated CI/CD checks pass?

Changes to Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you included examples of how to use your new feature(s)?
• Have you updated all website and readme documentation affected by the changes you made?

[iMichaela]

@david-waltermire - I do not contest there are benefits from simplifying the oscal-cli commands, but ALL CI/CD pipelines and Makefile using the oscal-cli today will no longer work, and NIST/OSCAL project is not the only one using it. This change is not a backwards compatible change, and it should not be approved without OSCAL community's review & feedback, and not without a major release. It affects too many projects & people.
You indicated that current command pathway has been deprecated, but still work for backwards compatibility - but for how long, and why not creating a major release?

[david-waltermire]

The goals for this change are to:

1. Provide a more usable, user-friendly approach to performing common OSCAL content actions (i.e., conversion, validation, profile resolution). The current command pathways are a bit cumbersome, as they require selecting the model used, which in automation use cases requires external tracking of the model. The liboscal-java has had support for model detection for a long time, which hasn't been used. These changes make use of this functionality to simplify the command paths and to eliminate the need to externally determine the model.
2. Ensure that support for the existing command pathways remains. Eliminating existing command pathways is disruptive and will affect current uses of the tool. Since this change focuses on usability, breaking current use would be counter to this.
3. Promote use of the new pathways. Inclusion of a deprecation warning is a good way to signal this in a low-impact way. This also makes it possible to remove the old pathways at some point in time when the community is ready.

This change is backwards compatible. It does not remove the existing pathways or change existing command behaviors; it adds new pathways, which are optional to use. This means it can be done in a minor release.

Removal of any pathway should be done through a separate change at a future date, in a future major release. Determining when this will happen needs to be coordinated with the user community. It would be reasonable to allow for a year or so for changes in use to be made. I really don't have a strong opinion around when, only around ensuring that users are not caught off guard by a change. When there is a desire to remove the commands, I would expect this to be socialized for a lengthy period of time before releasing that change.

I hope this clears up the intent.

If there is interest, the FedRAMP team can probably help with migration to using the new command syntax in the NIST OSCAL repo CI/CD. It shouldn't be much work to do this. This is something we can do through PRs, also providing an easy way to review the changes and test the workflows.

[iMichaela]

@david-waltermire - Thank you for all detailed explanations. It makes sense. Supporting the community members' use of the tool without disruption was the trigger for the comment above.