Critical: Emojis should not be valid Org or Project names

[amplifi]

Steps to reproduce the error

DO NOT test this in any live environment (staging, demo, or production). Test in dev VM only!!

This bug breaks the platform and results in data corruption.

Create a new org, project, whatever and give it an emoji for a name. Click Save.

Actual behavior

Emoji is saved as the entity's name, and the platform dies in a fire trying to display it.

Expected behavior

Don't allow emoji to be accepted by an input field on the platform. (Related but separate to #1157 )

[oliverroick]

I had a look at this and the problem was not so much the use of emojis per se but rather that the name contained only emojis. That resulted in an empty slug which broke the platform. If you have a name like "I need 🍺" everything is ok because the resulting slug is i-need.

We can make emoji-only names for organizations and projects work, if we use a default slug whenever slugifying a name results in an empty slug. I have a solution ready that uses the model name, so if the organization's or project's name is just "🍺🍺🍺🍺" the resulting slug would be organization or project, respectively.

The question is: Do we want to allow emojis at all? My take is, why not? And if yes, is the proposed solution using the model name acceptable?

If we decide not to allow emojis the solution is more complex and will be folded together with #1157.

[amplifi]

The empty slug broke the platform, but the emoji char also caused breaks in ElasticSearch. If we're going to support emoji we'll need to make sure it's supported throughout; ES, imports, exports, ODK, etc.

[linzjax]

I've been using emoji's when testing ODK on my local-env and they translated to the platform without any complaints, but that was before we had ES.