Normalize emails_[en/dis]abled param response in API
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=458823)
</details>
<!--IssueSummary end-->
The following discussion from !151065 should be addressed:
- [ ] @hfyngvason started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/151065#note_1885926507): (+2 comments)
> What should happen if both are provided? The way it is right now, the deprecated field always wins, which seems like the opposite of what we want. Options:
>
> 1. keep things as-is
> 2. non-deprecated field wins
> 3. or, be a 400 if both are present and they have inconsistent values
> 4. or, always be a 400 when both are present
>
> I like (3) because it catches probable bugs while also enabling the same code to support multiple GitLab versions (especially important during a zero-downtime upgrade). Conversely, I don't like (4) because that would complicate such upgrades.
>
> What do you think?
issue