Add a GitHub Action for Data Releases

[brendagutman]

Harmonizers will need to see changes that occurred between releases, related process' can be automated. Consistent tagging, release note creation, dd and enumeration file generation and storage.

Eventually the process of pulling data dictionaries and enumerations from this repo will be automated, and the generation of those files can be done at the time of release and the information stored with the project-artifacts as is done here.

[RobertJCarroll]

It would be helpful to have Eric set up the release tooling.

With regards to the release notes, we should also set some expectations around PR and commit titles/descriptions. Or some other way to do a diff between the models to highlight the changes. Any ideas?

[brendagutman]

1. I agree that we need set expectations, but these depend on the user/use case.

a. Harmonizers would want to easily parse the changes directly related to harmonization.
a.1 We would likely find the most use out of the GitHub UI comparison of the linkml, or datadictionary/enum csvs(if they are versioned in this repo).
a.2 Versioning dds and enum csvs could be done in the pipeline repo instead of in the model repo. Move the use of ftd-dd to create the data dictionary and enumerations files into the pipeline-utils. Keep the data dictionaries and enumerations that are currently being used, versioned in the pipeline repo. A harmonizer can easily pull down the release that they want and see the diffs in their local working dir.

b. Other users would most likely want to see past discussions of a topic.
b.1 GH Issues could cover that need. Any true modeling discussions should be within Issues, and not in PRs. PR discussions can link to Issues, but should only contain comments about the implementation of the code.
Or instead of Issues, we could use another tool. Perhaps GitHub discussions, but I haven't looked into it.
b.2 I'm not sure if strict PR titles and descriptions are that necessary. Perhaps gitmojis could help tag large PRs vs small tweaks/bugs.

2. Other ideas to keep Release comparisons clean for harmonization.
   a. Decide on a linter. I'd rather not have to parse true changes from format changes.