Implement instance-level $validate and enforce mode binding

[lmsurpre]

Is your feature request related to a problem? Please describe.
In #2905 we added partial support for the mode input parameter on the $validate operation.
Specifically, when this parameter is set to create or update, we will validate the passed resource by using the corresponding fhir-server-config settings under resources/<resourceType>/profiles.

However, https://www.hl7.org/fhir/operation-resource-validate.html defines mode with a required binding to https://www.hl7.org/fhir/valueset-resource-validation-mode.html whereas our implementation allows any string that would be a valid code.

Specifically, in addition to create and update modes, it defines:

• a profile mode that it says should only apply to a resource "nominated by id, not provided as a parameter"
• a delete mode that only makes sense against a previously-ingested resource

But our implementation doesn't even support validation against existing resources in the db.
If you try invoking it at this level, it fails with a 400 Bad Request error that says:

"Input parameter 'resource' is required for the $validate operation"

Describe the solution you'd like

1. Support (and advertise support for) resource-instance level $validate (at [base]/[resourceType]/[id]/$validate)
2. Ensure that only valid "mode" codes are accepted by the $validate operation... if an invalid code is sent then return a 400 Bad Request with a reasonable error

• Ensure delete is only ever invoked at the resource-instance level (although I have no clue when we'd say that a given delete is "invalid"...I guess never?)
• I don't understand why profile wouldn't be used when validating a passed resource against a particular profile. I think this matches our current behavior if the 'profile' parameter is passed in and that seems fine to me.

Describe alternatives you've considered

Acceptance Criteria

1. GIVEN [a precondition]
   AND [another precondition]
   WHEN [test step]
   AND [test step]
   THEN [verification step]
   AND [verification step]

Additional context

[punktilious]

I found a couple of possible issues:

1. Minor. If a resource is delete, if you try to delete it again you get 200 OK with an OperationOutcome indicating that the resource is already deleted (the operation is idempotent). However, validate mode=delete will give you a 404 for a resource which is currently deleted. So that's a slight discrepancy.
2. The validate mode create/update/delete appear to ignore the allowed interactions configuration. For example, I think if we disable delete, then validate mode=delete should also say that the resource cannot be deleted.
3. Validate mode=create indicates no error when the resource currently exists. I'm struggling with what should be the correct behavior for this one because the spec says: "and then checks that the content would be acceptable as a create (e.g. that the content would not violate any uniqueness constraints)"
4. With updateCreateEnabled set to false, the validate mode=update operation reports NoError even when the resource does not exist
5. Validate mode=create shows no error if no resource parameter value is provided.
6. Validate mode=update shows no error if no resource parameter value is provided.