should stcal use steps as the top-level sections in the change log, like jwst does?

[zacharyburnett]

The manually-made changelog before #284 had General, Bug Fixes, and Changes to API. as top-level headers, and then steps as subheaders underneath that:

stcal/CHANGES.rst

Lines 15 to 46 in c1a8bab

	1.7.3 (2024-07-05)
	==================
	Bug Fixes
	---------
	ramp_fitting
	~~~~~~~~~~~~
	- Fix bugs in the C algorithm Poisson variance calculation when provided with
	an average dark current. [#269]
	- When OLS_C was selected as the ramp fitting algorithm with multiprocessing, the C
	extension was not called. The old python code was called. This bug has been fixed,
	so the C extension is properly run when selecting multiprocessing. [#268]
	1.7.2 (2024-06-12)
	==================
	General
	-------
	- build with Numpy 2.0 release candidate [#260]
	Bug Fixes
	---------
	jump
	~~~~
	- Flag asymmetrical snowballs that are missed by the current code (JP-3638). This was changed to
	not require that the center of the snowball jump ellipse is a saturated
	pixel. [#261]

However, towncrier only supports creating one level of header, so in #284 I kept the top-level ones and recommended prepending [ramp_fitting], [jump], etc. to the front of the change log entry to make it clearer which entry affects which step:

stcal/changes/278.apichange.rst

Line 1 in b9b0f8d

[ramp_fitting] Add the likelihood algorithm to ramp fitting.

Should we change the change log sections (fragment types) to be more like jwst's change log (steps as top-level headers)?

This would change the fragment filename from changes/299.bugfix.rst to changes/299.ramp_fitting.rst, and involve changing these types to every possible step:

stcal/pyproject.toml

Lines 261 to 268 in c1a8bab

	[tool.towncrier.fragment.apichange]
	name = "Changes to API"
	[tool.towncrier.fragment.bugfix]
	name = "Bug Fixes"
	[tool.towncrier.fragment.general]
	name = "General"