RAD-229: Clean up the documentation after all the RAD updates.

[WilliamJamieson]

Resolves RAD-229

Closes #713
Closes #683

This PR makes updates to the docs.

Tasks

• Update or add relevant rad tests.
• Update relevant docstrings and / or docs/ page.
• Does this PR change any schema files?
  • Schema changes were discussed at RAD Review Board meeting.
• Does this PR change any API used downstream? (If not, label with no-changelog-entry-needed.)
  • Write news fragment(s) in changes/: echo "changed something" > changes/<PR#>.<changetype>.rst (see below for change types).
  • Start a romancal regression test (https://github.com/spacetelescope/RegressionTests/actions/workflows/romancal.yml) with this branch installed ("git+https://github.com/<fork>/rad@<branch>").
  • Update relevant roman_datamodels utilities and tests.

News fragment change types:

• changes/<PR#>.feature.rst: new feature
• changes/<PR#>.bugfix.rst: fixes an issue
• changes/<PR#>.doc.rst: documentation change
• changes/<PR#>.removal.rst: deprecation or removal of public API
• changes/<PR#>.misc.rst: infrastructure or miscellaneous change

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.89%. Comparing base (58eb8dd) to head (42ec6b2).
⚠️ Report is 119 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #745      +/-   ##
==========================================
- Coverage   97.76%   88.89%   -8.87%     
==========================================
  Files           8       14       +6     
  Lines         759     1018     +259     
==========================================
+ Hits          742      905     +163     
- Misses         17      113      +96     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[schlafly]

This looks great, thanks William. I have a few minor grammar / wording changes. I also reworded the paragraph about "don't introduce new internal tags"; if I screwed it up in my suggested rewording, please discard!

[schlafly]

Suggested change

	In most cases you will not tag a schema. These are generally, when the schema
	is not intended to be used as a datamodel. This allows for easy reuse of schemas
	and extending another schema, see :ref:`pseudo-inheritance` for more information.
	Internal schemas that describe only part of a datamodel should not be tagged. These
	internal schemas are generally used when multiple datamodels or parts of the metadata
	want to reuse or extend the same information. See :ref:`pseudo-inheritance` for more information.