add new invite/<token_type>/check/<token> endpoint

having `/invite/service/<token>` and `/invite/service/<id>` as two
separate routes (the first to validate an invite token, the second to
retrieve invite metadata) technically works. Routes are matched from
first to last until a match is found. The metadata endpoint only accepts
UUIDs, so requests with a UUID will be picked up by the correct
endpoint, while requests that don't look like a UUID will carry on
searching for an endpoint, and will find the token validation endpoint.

So while this works correctly for our normal expected input, it only
does so _because the UUID endpoint is first in the file_. This isn't
great, and it makes it harder to reason about the URLs when looking at
them.

To solve this, create the new `invite/service/check/<token>` endpoint.
For backwards compatibility, assign this in parallel with the existing
route - once the admin uses the new route we can remove the old route
and make better guarantees about what endpoint is being hit.

tests/app/organisation/test_invite_rest.py

@@ -183,10 +183,15 @@ def test_update_org_invited_user_for_invalid_data_returns_400(admin_request, sam
     assert json_resp['errors'][0]['message'] == 'status garbage is not one of [pending, accepted, cancelled]'
 
 
-def test_validate_invitation_token_returns_200_when_token_valid(client, sample_invited_org_user):
+@pytest.mark.parametrize('endpoint_format_str', [
+    '/invite/organisation/{}',
+    '/invite/organisation/check/{}',
+])
+def test_validate_invitation_token_returns_200_when_token_valid(client, sample_invited_org_user, endpoint_format_str):
     token = generate_token(str(sample_invited_org_user.id), current_app.config['SECRET_KEY'],
                            current_app.config['DANGEROUS_SALT'])
-    url = '/invite/organisation/{}'.format(token)
+
+    url = endpoint_format_str.format(token)
     auth_header = create_authorization_header()
     response = client.get(url, headers=[('Content-Type', 'application/json'), auth_header])