Emoji handling is inconsistent

[SkylerRingtail]

Different fields of the application handle emojis differently. For example:

1. Some fields, such as the legal name field, give an in-line "No fields may contain emoji characters" error on submission.
2. Some fields, such as the Emergency Contact field, give an error popup on submission (upper right corner) that reads "Fields cannot contain emoji" (also note the lack of a period in this error message.
3. Some fields, such as badge name, have unique error messages.

These error messages should ideally be treated more consistently. At the least, cases 1 and 2 (for non-uniquely-handled fields) should behave identically. Personally, I prefer the in-line error of 1, but this does go against our general error format of pop-up dialogue bubbles.

[kitsuta]

This is largely fixed in MidwestFurryFandom/mff-rams-plugin#111. There's still a few odd fields out: the badge name field, the email address field, the date of birth field, and the country field.

The badge name field has a much wider range of restricted characters than just emoji, but that restriction includes emoji, and the structure of the app means we hit the wider restriction first. We can fix this relatively easily, but I'm not sure it's helpful to first tell an attendee that their badge name can't have emojis and then when they edit it, tell them it also can't have other non-alphanumeric/symbol characters.

The other fields all have clientside validation that renders emoji invalid. These validations come from the various jQuery plugins that power these fields: jquery-datetextentry for the DOB, selectToAutocomplete for the country field, and uh... I don't actually know which plugin validates the email address field. Ripping out this validation for the sake of consistency makes basically no sense, which is probably also why these fields weren't mentioned in the original issue. :)

So basically we have a choice to either force the emoji message to show for badge name, or to not do that.

[jmdawson]

Fixing this more thoroughly than MidwestFurryFandom/mff-rams-plugin#111 does can wait until 2019.

[jmdawson]

This is all stuff that QA etc can poke at at some point, but doesn't need to be changed until 2022. Reasonable to get a PR going before then though.