Redesign information architecture of rules table columns and rule doc notices for representing rule configs/severities

[bmish]

This is a substantial redesign of how we represent the configs that a rule belongs to in order to better account for the different error/warn/off severities that a config can set a rule to. This completely replaces the previous design of using emoji superscripts to represent different config severity levels which turned out to be too fragile (fixes #204). I consider this a substantial improvement.

In the readme rules list, there is now a separate config column for each severity level present. The rules list legends and rule doc notices are also affected. See the diffs from the snapshots in this PR. I have also manually tested this in a variety of repos.

Benefits:

• Improved aesthetics.
• Emoji placement is more consistent. A config's emoji will always be displayed next to its name.
• No more overloading the same emoji to mean different things depending on the context.
• Config column header emojis and rule doc notice leading emojis now depend solely on the config severities present and no longer depend on the number of involved configs. This is also more consistent with the convention for leading emojis of the consolidated fixable/suggestions notice.
• The implementation is simpler and I have refactored a bunch.

Notes:

• The default emoji for warnings configs has changed to 🚸 to avoid a conflict with the emoji which represents a config that sets a rule to warn (⚠️).
• We now disallow the use of reserved emojis to avoid that whole class of problems and confusion.
• This is breaking in that the