Initialize transient fields with empty HashMap instead of null

[janvanmansum]

What this PR does / why we need it:
It resolves a bug in the ShowMuteOptions feature.

Which issue(s) this PR closes:

Closes #9029

Special notes for your reviewer:
It seems edu.harvard.iq.dataverse.authorization.users.AuthenticatedUser#postLoad is not executed in the scenario described in the issue (user was just created by a first federated login).

Suggestions on how to test this:

1. Log in with an IdP that you haven't used with the Dataverse instance before.
2. Create an account
3. Navigate to "Account Settings"

Does this PR introduce a user interface change? If mockups are available, please link/include them here:
No

Is there a release notes update needed for this change?:
No

Additional documentation:
N/a

[coveralls]

Coverage increased (+0.0008%) to 19.881% when pulling d8c3f6a on DANS-KNAW:9029 into 9686ab8 on IQSS:develop.

[pdurbin]

@janvanmansum thanks! There is another proposed fix here:

• nullpointer fix when getting notification with newly created user #8969

[ErykKul]

Hi. Both fixes have exactly the same effect: assigning empty hash sets i.s.o. null to these fields. However, #8969 is more defensive, as it ensures that newly created users are initialized exactly the same way as the users loaded from the DB. If anything changed in the future, both ways of initialization of the users (the only ones that I am aware of) reuse the same code to ensure a consistent state of the AuthenticateUser object. This decreases the chance of breaking the code in the future.

[janvanmansum]

The only advantage of #9030 I could point out is that postLoad does not have to become public. Either solution is fine with me though.

[mreekie]

This one will be resolved by #8969 and can be closed