Description
This PR changes the webservice to use WorkflowVersion.lastModified, which for most workflows is the time at which the corresponding tag was created on GitHub, to generate the version DOI publication date.

In general, this change will make the version DOIs appear in a sane order, but may cause ordering problems when subsequent retroactive automatic DOIs are added to workflows that had pre-existing non-automatic DOIs, or pre-existing automatic DOIs that were generated for tags found when our GitHub app was installed. Fortunately, this is a small number of workflows.

Somewhat suboptimally, Zenodo accepts a date, but not a date+time, in the publication date field for a submission (https://help.zenodo.org/docs/deposit/describe-records/publication-date/). So, if there's lots of tags created the same day, they may still appear "out of order". This includes the DOIs that are produced for DockstoreTestUser4's workflow [when the smoke tests are run?].

Review Instructions
Generate a sandbox DOI for a tag and confirm that the publication date is the tag's GitHub creation date, rather than the current time. This may be tricky. Alternatively, check the sandbox Zenodo Dockstore community for version DOIs wherein the upload and publication dates do not match, and confirm that the publication date matches the tag creation date.

Issue
https://ucsc-cgl.atlassian.net/browse/SEAB-7080

Security and Privacy

If there are any concerns that require extra attention from the security team, highlight them here and check the box when complete.

• Security and Privacy assessed

e.g. Does this change...

• Any user data we collect, or data location?
• Access control, authentication or authorization?
• Encryption features?

Please make sure that you've checked the following before submitting your pull request. Thanks!

• Check that you pass the basic style checks and unit tests by running mvn clean install
• Ensure that the PR targets the correct branch. Check the milestone or fix version of the ticket.
• Follow the existing JPA patterns for queries, using named parameters, to avoid SQL injection
• If you are changing dependencies, check the Snyk status check or the dashboard to ensure you are not introducing new high/critical vulnerabilities
• Assume that inputs to the API can be malicious, and sanitize and/or check for Denial of Service type values, e.g., massive sizes
• Do not serve user-uploaded binary images through the Dockstore API
• Ensure that endpoints that only allow privileged access enforce that with the @RolesAllowed annotation
• Do not create cookies, although this may change in the future
• If this PR is for a user-facing feature, create and link a documentation ticket for this feature (usually in the same milestone as the linked issue). Style points if you create a documentation PR directly and link that instead.