Better power level checking, part 1

[KitsuneRal]

This PR is the first, API-breaking, part of additional facilities to simplify answering a question "am I allowed to do X?". While porting Quaternion to libQuotient 0.9, I thought that it would be great to have something like Room::canRedact() - turned out though that actually figuring out whether you can redact a certain event is not that easy to answer (and the spec doesn't seem to be very clear in that part). So I will propose can*() methods as an API/ABI-compatible addition after 0.9.0 is out (once I make them right) but here's some groundwork that needs to come in 0.9.0.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
2 Accepted issues

Measures
0 Security Hotspots
66.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[TobiasFella]

is it expected that this breaks compilation of code like

m_room->setState<Quotient::RoomPowerLevelsEvent>(QJsonObject());

[KitsuneRal]

Rather not; I'll check what's going on.

[KitsuneRal]

m_room->setState<Quotient::RoomPowerLevelsEvent>(QJsonObject());

Ok, I didn't intend to break the legitimate things; that being said, this one is not quite legitimate. Below is the write-up for documentation's sake; TL;DR is that you should avoid using empty JSON to initialise events, since pre-0.8 you should be able to "default-construct" (most of) them with an empty list of arguments instead.

So, unimportant historical details: what used to be happening before is the empty QJsonObject was (effectively implicitly) converted to PowerLevelEventContent because unlike most other event types PowerLevelEventContent had a constructor accepting QJsonObject, and the StateEvent<> constructor used that constructor on the arguments passed to setState() in line with the emplace-idiom (creating an owned object in-place from its arguments). The problem is that, unless you go ~5 levels deep into the call hiearchy in the library code, it is not clear whether that QJsonObject is used to create an event object or merely the content part of it. This is why constructors in Event/RoomEvent etc. that accept QJsonObject have been made private since libQuotient 0.7, in particular; and around the same time, most event content structures were made default-constructible. RoomPowerLevelsEvent and PowerLevelsEventContent were initially made based on EventContent:: classes, that is - with a QJsonObject constructor and fillJson() method. However, the only reason EventContent:: classes were made this way has been because they are polymorphic. PowerLevelsEventContent doesn't need polymorphism; and in any case it had to have the defaults defined within the structure, rather than rely on the event class correctly filling them (which has been the way it all worked before the big event types refactoring in 0.7).

Back to important stuff. To provide cross-compatible code, I can suggest explicitly creating a PowerLevelEventContent object by writing m_room->setState<RoomPowerLevelEvent>(fromJson<PowerLevelEventContent>(QJsonObject{}));. If there are too many such places then I can restore (and immediately deprecate) PowerLevelEventContent::PowerLevelEventContent(const QJsonObject&) - but I'd prefer to avoid that.