Deprecate use of members API for invite modal in favor of invitations API

Problem

Currently when inviting someone to be a member in the invite modal, we make 2 calls to the API

1. /members with invites that are to current users.
2. /invitations with invites that are to emails(not current users).

Each endpoint responds differently when encountering an error.

This causes downstream issues in response codes and how errors are handled in the response.

• invitations endpoint provides a json object with each email being a key in a hash.
• members endpoint provides a json object with each user being an element of an array.

This isn't sustainable and will only cause more issues when trying to deal with errors in the display and also extending.

Solution

• Ensure the error responses and status codes are the same when submitting emails or users from the invite modal.
  • extend the /invitations API to handle both users and emails, deprecating the use of /members from the invite modal.
  • see #353008 in case we deprecate a parameter here.
  • resolve with !80733 (merged)
• Remove the specific parsing of the members API from the invite modal error parser
  • this will need to be a separate MR from the one above due to possible mixed deployments where FE and BE code can be out of sync.
  • resolve with !80733 (merged)
• Improve messaging when attempting to lower an inherited user's access level - see https://gitlab.com/gitlab-org/gitlab/-/issues/247208#note_843335734
  • resolve with !80733 (merged)
• Allow inherited users to be re-invited at a higher role than their current inherited role - will resolve https://gitlab.com/gitlab-org/gitlab/-/issues/247208#note_835103747
  • resolve with !80733 (merged)
• Investigate the possibility of combining the invites from the invite modal into one submission to the /invitations API.
  • if it does seem achievable, open a new issue to implement as the final step of completing this issue.
  • resolve with !80733 (merged)