Add endpoint for explicitly requesting SubmissionMetadata lock

[pkalita-lbl]

These changes are in support of having the Field Notes app respect the locked_by field on SubmissionMetadata records (microbiomedata/nmdc-field-notes#90). There are two issues I'm trying to address here:

1. The Field Notes app attempts to cache and reuse responses from GET requests whenever possible. The underlying assumption of the caching layer is that GET requests have no side effects. Currently, however, a request to GET /metadata_submission/{id} may also modify the record being returned by updating the locked_by field.
2. The Submission Portal has a unified view/edit interface for SubmissionMetadata records, whereas the the Field Notes app allows you to view a SubmissionMetadata before allowing the user to navigate to a separate edit interface. There would be no reason to read or write the locked_by field from the view interface.

To address both of those issues, these changes introduce a separate /metadata_submission/{id}/lock endpoint (called with a PUT method). This seemed like a natural counterpart to the existing /metadata_submission/{id}/unlock endpoint. Both of these endpoints now return a LockOperationResult object which indicates whether the lock or unlock was successful and who (if anyone) now holds the lock. Unsuccessful operations are also returned with a 409 Conflict status. With the assumption that a client should explicitly request the lock before making updates, there is no longer an attempt to claim the lock in the GET /metadata_submission/{id} handler.

On the frontend side there was only one function (see: web/src/views/SubmissionPortal/store/index.ts) where the GET /metadata_submission/{id} endpoint was invoked. So to keep the Submission Portal behaving the same way it did before, I added a call to PUT /metadata_submission/{id}/lock in that function. While testing I fixed a minor issues where there was an unnecessary extra call to getRecord (in web/src/views/SubmissionPortal/Components/SubmissionList.vue).

Tangentially related, there was another bug where a link presented in the "this submission is locked" case was forcing a full page refresh instead of client-side navigation (using <a> instead of <router-link>). Fixing that bug revealed that the isEditingSubmission state in StepperView was not correctly reacting to route changes. This is fixed by using the existing id prop on the component instead of getting it from the route.

[naglepuff]

LGTM! Thanks for addressing the issue with try_get_submission_lock