Revising trestle plan to accommodate latest scenarios.

[butler54]

Conceptual design choices here need to make it into the developer documentation.

With the evolution of trestle 'SAGA' style orchestration has been excluded which was one of the original intents of plan. Most of this is dealt with by an external tool, such as a CI pipeline.

This produces a simpler usecase for trestle plan. It is principally to ensure that when managing multiple files if there is an error the files do not end up in an inconsistent state (e.g. we do not deal with external APIs - we primarily deal with the file system).

Under this scenario there are two likely forms of errors which we can handle:

• Internal errors due to buggy code (unhandled scenarios in complex oscal models or a failure to validate).
• Users manually editing files / adding extra files which are unhandled.

With both of these scenarios we need to ensure that changes are non-destructive.

What we cannot handle easily:

• IO issues on the disk (there is no meaningful fallback)
• User induced destructive changes which are not revert-able using a git history or similar (also know as we recommend using git to manage files .. commits are easy to roll back :-) )

Architectural design decisions:

• Looking at trestle plan (internally) there may be the opportunity to make the code more pythonic if it is revised.

Extension points required:

• Interaction with markdown files is definitely required

Trestle commands where it may be required:

• trestle author ssp-, trestle author catalog-, trestle author profile-*, Potentially for transforms.