Remove t from invite-related code

[hmhealey]

Summary

This is the first part of my mission to eradicate t from last week. Most of it is pretty straightforward replacement of t with defineMessage/defineMessages, and I also occasionally removed some use of localizeMessage as well, but I'll comment on anything noteworthy below.

Ticket Link

https://mattermost.atlassian.net/browse/MM-58324

Release Note

NONE

[hmhealey]

To get rid of localizeMessage here, I made reason contain a MessageDescriptor instead of the translated string so that the UI can translate it once it reaches there.

I also made the conscious decision here to repeatedly call defineMessage here instead of grouping these together in a big defineMessages below because leaving it this way made the diff so much easier to read. Ideally, I think we'd rewrite this a bit to avoid the deeply nested objects and repeated calls to defineMessage for repeated strings, but I decided not to do that at this time

[hmhealey]

I had to partly revert that because we still had code that set reason to be an error string from the server in some cases. Unfortunately, I didn't catch that earlier because I assumed that the type check would fail when I made it not possible for it to be a string, but because response.error is an any, it wasn't reported

[hmhealey]

Changing reason to a MessageDescriptor also let me get rid of injectIntl here

[hmhealey]

This is one of a few places where we went from passing in separate ID/default props and now we just pass in a single MessageDescriptor for each piece of text

[larkox]

Great work, just a few nitpicks.

[larkox]

Not sure why we are mixing having the messages object, and also using the identifiers directly here. 0/5

[hmhealey]

Yeah, we haven't really standardized on passing around strings vs message descriptors. For this, I tried to keep them as-is to reduce the scope of these changes.

I've been thinking about if I'd prefer passing around descriptors or strings/components in more places if we were consistent everywhere. My gut reaction would be that passing descriptors would be better, but it makes passing values into those trickier values isn't part of MessageDescriptor. It's also less idiomatic than passing a FormattedMessage when you're rendering something, but some people also avoid FormattedMessage even when it should arguably be used

[larkox]

We could make things more complicated and create a "valued message descriptor" that we would have to process where it is used to get the proper string and values. Something like type VMessageDescriptor = MessageDescriptor & {values?: ValuesType}. Then we will have something like function renderValuedDescriptor(vd, intl) { return intl.formatMessage({id: vd.id, defaultMessage: vd.defaultMessage}, vd.values);}.

But 0/5 on that approach. Maybe we can figure out something in the middle that make sense.

[hmhealey]

There's a few places we have done that, but I'm not sure if I'd want to do that everywhere because it is nice to encourage people to not overuse values in cases where they should just have two separate strings. Values also don't always work when the message is being used for an aria-label or something else that needs text.

For now, I'll leave it -as-is, but I'm going to keep thinking about this since it would be nice if there was a good solution for this that worked everywhere