Invitation API - UserRoleAssignment Invitation - Add existing user to a context that the user has no roles

[defstat]

Describe the bug
Adding support UserRoleAssignment Invitation - Add existing user to a context that the user has no roles.

The requirement is that a Context (Journal for example) manager that searches for a user by his email for example, should not be able to get the information of the user if that user is present in the installation as part of another Context.

To facilitate that changes must be made in the backoffice so that:

1. The interface should act in this case as the user is a new one. The manager should stay agnostic of the fact that a user with this email already exists
2. After the invitation is send, the manager should see what ever data are provided in the creation stage, no matter what the invitee is changing on the receive part of the invitation.
3. On the receive part, if the given email belongs to an existing user, the UI should act like so, and provide the user with the "existing user" flow.

---

PRs

pkp-lib: #10631

[defstat]

@ipula as part of this PR (find the PR in the first comment) I made the following changes:

1. Changed the Invitations/getMany endpoint of the so that you must provide the type of the invitation as such useApiUrl('invitations/userRoleAssignment') - All the other parameters of this call stay the same.
2. When the user accepts the invitation, a check is made for whether the provided email exists. If it does, I change the invitation core data, adding the user_id of the existing user and changing the email to null. From this point on, the UI should act as there is an existing user available

Please check if those changes cover the case we discussed.

[ipula]

@defstat @withanage I tested and works fine for me.

1.Invite new user in Journal A

2. Accept invitation in Journal A
   

3. Create user in Journal A
   

4.Invite same user to Journal B

5.User in the invitation list

6.Accept invitation to Journal B

7.Create user account in Journal B

8.Login user into OJS Journal B

9.Switch to Journal A

[defstat]

@asmecher @ewhanson Can you review that PR?

[ewhanson]

Note for @ewhanson, #9661 will need to be updated to take into account changes here once merged.

[defstat]

Everything merged in main . Thanks @ewhanson

cc: @withanage @ipula

[defstat]

@withanage @ipula the latest merge brakes the tests, because of a change in the API - The UI had not followed the change (or it was not yet merged).

The change is this [UI_LIBRARY]: pkp/ui-library#472 and #10755 and I am waiting for the tests to pass here [OJS]: pkp/ojs#4573

[defstat]

@withanage @ipula I have merged the two PRs (see here), because they where causing the tests to fail, thus closing this for the moment. But please take into account the ui-lib change that was just merged.