Simplify document loading

[laurelmay]

Description

As a user of the OSCAL Viewer, I want to paste a URL and have it "just work" without giving a validation error because I gave a URL to a Profile instead of Catalog.

Acceptance Criteria

• All existing Viewer routes continue to exist but functionally work the same way (for any document URL given, it is loaded)
  • This means /catalog/?url=A_PROFILE should display the profile without error
  • This is necessary to preserve existing URLs and ensure they continue to function
• The "homepage" (/) no longer displays the Catalog Viewer by default but instead more of a welcome text with the "OSCAL Loader Form" to allow specifying a URL
  • It would likely be helpful to have a few example documents on this page to choose from
• All routes in the Editor continue to function exactly as they do today
• Hamburger menu navigation is removed in the Viewer (editor navigation is unchanged)
• The new preferred method is simply https://viewer.oscal.io/?url= and documentation/samples are updated to use this

Proposed Solution

This probably requires pretty extensive changes to the OSCALLoader and OSCALLoaderForm but with the Convert.toOscal function, it should be feasible to determine which document type we have (based on which field is populated).

The majority of the "friendly" bits for this (the new welcome page, etc) need to be defined in the oscal-viewer package rather than included in the library. At the same time, it would be great to remove all Route-based stuff from the oscal-react-library if any is still present.

Additional Notes

This is a good "first step" to refactoring OSCALLoader and OSCALLoaderForm as it forces us to more dynamically handle the document type while still allowing us to maintain assumptions about having an entire document.

Implementation

• I can (or plan to) submit a pull request to implement this
• Implementing this may result in a breaking change

[brian-ruf-ezd]

Assumption: Error handling will function the same way it has. No change in error handling mechanisms.

[Bronstrom]

6/8/23 Sprint Planning - Moved from Sprint 48 to Sprint 49

[Bronstrom]

6/22/23 Sprint Planning - Moved from Sprint 49 to Sprint 50

[Bronstrom]

7/6/23 Sprint Planning - Removed from sprint board. Planning to return to this issue at a later date.