refactor(plugin): make use of native mkdocs.event_priority

[ultrabug]

use mkdocs event_priority to control the events execution order of this plugin (always last)

[ultrabug]

FYI @kamilkrzyskow

[kamilkrzyskow]

Do you @ultrabug perhaps have a short explanation why exactly does the plugin mimic the behavior of MkDocs when building alternate languages? Wouldn't it be possible to create a custom mkdocs.yml on_post_build and call the internal MkDocs build procedure from the start all over, and then finally when all of the langues are finished it would copy the files from those separate builds back to the initial one combining it all into one. I'm asking if that's a technical limitation of MkDocs or design choice of the plugin that is currently too deeply developed to refactor it? 🤔

A lot of people use the Material theme with a bunch of different Insiders plugins that could bring their own issues when this plugin needs to "handhold" the process of running events 🤔

As for the event priorities I think that a lot of plugins would choose to have -100 to make sure they're working on the "latests" version of any config, env, etc. 😆 However, it sure helps when they use the default.

---

As a side-note, after pondering about it over the last 2 days. I will copy some parts of the awesome-pages Test Suite, since it does have a nice method of separating MkDocs builds. https://github.com/lukasgeiter/mkdocs-awesome-pages-plugin/blob/836098293872edda9df4576bd90759c253e1437c/mkdocs_awesome_pages_plugin/tests/e2e/base.py#L86 Still thinking about the cleanest way to introduce this kind of approach to the current testing suite 👌

[ultrabug]

I'm asking if that's a technical limitation of MkDocs or design choice of the plugin that is currently too deeply developed to refactor it?

MkDocs structure changed quite a lot since I wrote this plugin so lots of design decisions of this plugin come from some constraints of MkDocs 1.2 and of course from my own interpretation and initial suffix only design of the plugin.

More people than I initially thought actually adopted this plugin and I eventually ended up facing major requests such as the folder structure... which is not very intuitive with the initial design of this plugin.

TBH this plugin needs a deeper rewrite of its internal logic to leverage on newer MkDocs structure and take into account the two methods of providing translations.

I have ideas.. time is another story :)

This PR is a quick step into MkDocs newer structure as you can see.