Elixir 1.12 changed formatting rules, this allows to avoid having to rollback to run `mix format`

* Policies were put under a new module (Pleroma.Web.ActivityPub.MRF.Policy instead of Pleroma.Web.ActivityPub.MRF), but this wasn't changed in the Pleroma.Web.ActivityPub.MRF @mrf_config_descriptions
* I don't have a unit test to prevent similar problems in the future because I don't find a proper way to do it
    * The descriptions in the unit tests are defined in the unit tests, so if someone changes module names in the code, the tests wont see it
    * The list is generated in Pleroma.Docs.Generator.list_behaviour_implementations, but I can't do a check in the when clause of the function to see if the provided module is a behaviour or not.

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3509

* To see what front ends are installed, it ls static/frontends. When this folder doesn't exists yet, it will return an empty array.
* Installing still works since the folder is created during installation already

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3510

* To see what front ends are installed, it ls static/frontends. When this folder doesn't exists yet, it will return an empty array.
* Installing still works since the folder is created during installation already

* Policies were put under a new module (Pleroma.Web.ActivityPub.MRF.Policy instead of Pleroma.Web.ActivityPub.MRF), but this wasn't changed in the Pleroma.Web.ActivityPub.MRF @mrf_config_descriptions
* I don't have a unit test to prevent similar problems in the future because I don't find a proper way to do it
    * The descriptions in the unit tests are defined in the unit tests, so if someone changes module names in the code, the tests wont see it
    * The list is generated in Pleroma.Docs.Generator.list_behaviour_implementations, but I can't do a check in the when clause of the function to see if the provided module is a behaviour or not.

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3503

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3503

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3500

Closes: https://git.pleroma.social/pleroma/pleroma/-/issues/2740

Added a new field in the nodeinfo called quarantined_instances_info
This holds an object like `"quarantined_instances_info":{"quarantined_instances":{"quar.inst":{"reason":"whatever reason"}}}}`

* Only for SimplePolicy for now
* I added an extra mrf_simple_info key that has an object as value. The object contains only relevant extra info

It's easiest (and imo most proper) to use tuples {"instance, "reason"} in BE,
but for FE maps like %{"instance": "instance", "reason", "reason"} are better.
I changed it so that node_info returns maps now for simple_policy and quarantined instances.

When a setting was deprecated, the code would stop checking for the rest of the possible deprications. This also meant that the settings weren't rewritten to the new settings for deprecated settings besides the first one.

* Give deprecation message
* Rewrite configs

* This is for the settings, not yet a DB migration

No test was done for quarantined instances yet. I added a factory for followers_only notes and checked
* That no followers only post is send when the target server is quarantined
* That a followers only post is send when the target server is not quarantined

* Changed SimplePolicy
* I also grepped in test/ for ':mrf_simple' to see what other things could be affected

When strings are detected in the simplepolicy, a warning will be given and the config will be changed to use tuples instead