Allow invitations API to handle user invites as well as emails

What does this MR do and why?

• switch to use invitations API only for simplicity and standard error message formatting.
• only make one call to submit invites to the backend instead of 2.
  • this will greatly simplify the code and tests
  • possible downside is that performance could suffer for larger invites that have mixed users and emails...but I think that edge case tradeoff is worth it.
• switching to the invitations API also fixes the regression pointed out in https://gitlab.com/gitlab-org/gitlab/-/issues/247208#note_835103747 where users by username were no longer allowed to be re-invited since moving to the invite modal. This will fix that as well.
  • see https://gitlab.com/gitlab-org/gitlab/-/issues/247208#note_842523416 for info about how this will solve that issue as well.

#350999 (closed) will also add more details of the API use change.

Screenshots or screen recordings

no change. Only real UI change would be that we can now again re-invite members by username via invite modal - see https://gitlab.com/gitlab-org/gitlab/-/issues/247208#note_835103747

How to set up and validate locally

1. Visit any group or project member pages such as http://127.0.0.1:3000/groups/flightjs/-/group_members
2. Click the invite members button.
3. Attempt to invite by email and by username

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #350999 (closed)