Colored messages

This **huge** pull request adds message types. Different message types a colored differently in the message section of the sidebar and in the message log. Instead of new messages being red and a bit old messages being dark gray, new and and a bit older messages have a color depending on the mssage type. The aim is to improve usability.

It follows a list of used colors and their meanings.
First color is for fresh messages, second color is for slightly older messages. Old messages are always dark gray.
* white/light gray: Neutral event / no effect or only slight effect / non-critical failure of an action. This message type is the default one.
* light blue/blue: informational message (eg. usage description, tips, examination result)
* light green/green: Positive effect, something good happened. (Death of hostile enemy, good mutation, …)
* light yellow/brown: Warning, possible danger (eg. enemy spotted)
* light red/red: Something bad effect happened (eg. take damage)
* pink/magenta: Positive/bad effect mixed happened. (eg. gain a mutation with mixed effect)

Unused colors:
* light cyan
* cyan

(If you have an idea for one more message type, I would happily include it, using these colors, but in a different pull request)

Here are the most important parts of this PR:
1. Adding the enum `game_message_type` for the message types. It is documented in `messages.h`. It is listed in `ENUMS.md`.
2. Overloading `add_msg` (and friends in `messages.cpp`) with a new parameter `type`, of type `game_message_type`.
3. Overloading its wrapper (?) functions: `add_msg_if_player`, `add_msg_if_npc`, `add_msg_player_or_npc`.
4. Going through every call of the `add_msg` (and wrappers) and assigning them a message type. This is the part which took the most work.
5. Special treatment for mutations.

`add_msg` has been intentionally overloaded, not rewritten. The old function without the `type` parameter still exists. The message will be then of the neutral type (`m_neutral`). This has been done for convenience reasons so you don’t have to supply the `type` every time you call `add_msg`.

The special treatment for mutations works as this:
Determination of the proper message type if you just lose or gain a mutation is easy. If you gain a mutation, you get a “good” message if the mutation is good, a “bad” message if the mutation is bad, a “mixed” message if the mutation has `mixed_effect`. Neutral mutations produce a "neutral" message. If you lose a mutation, good and bad messages are reversed. This is straightforward.
The tricky part was to assign a message type if a mutation gets repaced. I have done it this way: Above all, if one of both mutations are mixed, the message is mixed. Period. If not, the points of the replacing mutation minus the points of the replaced mutation are compared. If the replacing mutation has more points, the message is positive, if it has less points, the message is negative. Otherwise it is neutral.
This behavior is different again if a natural trait is being replaced. Here the message is positive iff the replaced trait is bad and the replacing trait is good. This vise-versa produces a negative message. The message is neutral iff both traints are neutral, else the message is mixed. The two traits may be simply too different to surely be able to say “this is good/bad”, so better “play it safe” by using a “mixed” message more likely.
These methods to get the message type from mutation changes may seem strange, but so far they seem to work. But if you can find an example where the message color does not really fit the change, please say so!

There is one part of messages which is currently *not* coverd: Effects. This part seems to be in flux right now (probably port to JSON ongoing?), so I won’t touch this for now. Currently, all effects from JSON produce "neutral" messages, which is of course not always appropriate. I will try to tackle this *after* this PR is merged (it is big enough already!).

I took care I did not accidentally change any strings, but I have split a very few strings for style purposes, the additional load on translators is minimal.