Fix Version Table Archiving Submit logic

[qqmyers]

What this PR does / why we need it: The Dataset Page Version table shows info about the archival state of dataset versions (when archiving is used) and shows a submit button for superadmins to resubmit unarchived versions. However, the caching logic to decide whether a version can be archived (and therefore what to show in the table) was only designed for a single version and therefore caused info to display incorrectly when multiple versions exist.
This PR corrects the caching to be per version and updates the display to use the new per version info.

Which issue(s) this PR closes:

• Closes #

Special notes for your reviewer:
FWIW: This is one of several PRs related to updates being done to improve archiving scalability at QDR and DANS. Some are relatively minor cleanup while others are more significant. I'm submitting them all to avoid drift in QDR's fork and to leverage QDR testing (where all of these are being tested together).

Suggestions on how to test this: Could configure archiving per the guides but, since the display is run based on the recorded status in the datasetversion object, it may be easier to add status to multiple versions to show the difference. I think one simple case would be to have a v2 that hasn't been archived and a v1 that was successfully archived. With the current code, both versions will show/not show the submit button for a superuser. With the PR, submit should only be shown for the one where archiving was not successful.

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Is there a release notes update needed for this change?: Will create an aggregate one

Additional documentation:

[coveralls]

coverage: 24.333% (-0.001%) from 24.334%
when pulling 69dee01 on QualitativeDataRepository:Arch4-fix_isArchivable_caching
into cc37d4d on IQSS:develop.

[sekmiller]

@qqmyers When I try to run this I'm getting a No Such Method Exception on supportsDelete. I've set up my local to use LocalSubmitToArchiveCommand. It's unclear why we're checking for this method or what needs to be done in the setup to get it. Bottom Line is that versionArchivable is always returning false so I'm not seeing the submit button.

[qqmyers]

Sorry, it's an error in me trying to pull things apart for review - supportsDelete is part of #12103. I could drop it here, but I might suggest trying to run #12167 instead which has all the merged changes. (The idea at this point is to review all the PRs like this and not merge them, instead QAing and then merging #12167. So I could add a commit here to remove the supportsDelete part as long as that's never getting merged in the end, but any testing of functionality you do on this one would need to be repeated on the combined one.) Let me know if you want this one cleaned up.