Reconsider release versioning for updated data

[mjherzog]

We are creating SemVer Minor releases for this project every few days. Based on the CHANGELOG the only change for most of these releases is updated PURL data in the file purls.fst. I am concerned that this release versioning approach is confusing where the SemVer Minor version segment normally denotes a non-trivial (but not API- breaking) software change.

In the short-term I recommend that we use the SemVer Patch segment for an update that only affects the data file. I expect that this will add some complexity to the GH release workflow, but it should be feasible. We should also update the README to specifically explain the versioning approach.

In the longer-term I recommend we separate data updates from software updates where possible - i.e., where there is only a data update. A possible approach is to provide separate releases for the data when there is no software update and use a CalVer scheme to make the software and data-only releases distinct.

Both approaches should make it easier for downstream consumers to distinguish between software and data updates.

[mjherzog]

Philippe explained that we do need a new release for each data update because the data is embedded in the Go binary.
So the change to increment the patch release instead of minor release resolves this issue.