Introduce enum bitset and use it for monster flags and triggers

[codemime]

Summary

SUMMARY: Infrastructure "Introduce enum bitset and use it for monster flags and triggers"

Purpose of change

Monster flags/triggers were effectively duplicated in the mtype class: each stored as both std::set and std::bitset of enum entries. There's no point keeping around duplicated data and spend resources for maintaining its consistency, so only bitsets survived: a little benchmark showed that std::bitset is ten times faster than std::set for the purpose of accessing flags. However, plain bitsets aren't perfect for this either: they lack type-safety just like plain enums do.

Describe the solution

• Introduced a new template class enum_bitset for the purpose of handling enum class-based flag entries in a type-safe manner (essentially it's a wrapper around std::bitset), and applied it initially to monster flags/behavioral triggers;
• Got rid of sets and string accessors in mtype: working with string identifiers is error-prone due to typos, can be potentially slower, so it should be discouraged;
• Removed null entries for flags and triggers: they we useless;
• Slightly improved encapsulation of mtype;
• Turned string-to-enum maps into static constants (they were member variables);
• Converted monster triggers into an enum class. Didn't bother with converting flags, mostly out of laziness, but also to prevent oversizing the PR;
• Slightly adjusted serialization to make it work with the new class.

Describe alternatives you've considered

Leave everything as it is.

Additional context

Shoudn't introduce any changes in observable behavior.

[Night-Pryanik]

Refactoring isn't a valid possible summary line, I think Infrastructure fits best here.

[ZhilkinSerg]

Jenkins rebuild

[ifreund]

All looks good to me, just found one typo.