Read ETag support does not use version from meta if not found in id

[srdo]

Describe the bug
When the server decides whether to return 304 not modified on a request with an If-None-Match header, it only looks at the resource id version. It should look at the meta version.

A similar issue was #808

The effect of this is that you can send a GET with If-None-Match W/"1", and get back a 200 OK with ETag W/"1".

To Reproduce
Steps to reproduce the behavior:

1. Create a Read endpoint, where only the meta.versionId field is set in the response, to e.g. W/"1"
2. Send a GET request to the endpoint where If-None-Match is set to W/"1"
3. See that you get a 200 OK response

Expected behavior
You should get a 304.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• HAPI FHIR Version 3.7.0
• Windows
• Postman

Additional context
The bug is here https://github.com/jamesagnew/hapi-fhir/blob/dff2fdd3cfb07fcb6e64826e17c37f87768b63f7/hapi-fhir-server/src/main/java/ca/uhn/fhir/rest/server/method/ReadMethodBinding.java#L175. This line should be updated in a similar way to the code in issue 808. It might make sense to create a utility to extract resource version ids, so this doesn't pop up again.

There's a test here https://github.com/jamesagnew/hapi-fhir/blob/10d969c5145349f80e1f38a47b259c41e1003ced/hapi-fhir-structures-r4/src/test/java/ca/uhn/fhir/rest/server/ETagServerR4Test.java#L60 that would probably make sense to parameterize. It's being run with the version in the resource id, and not in meta. Adding a test that has the version in meta and not resource id would likely hit this issue.