Implement new Providers model

[rafaelmardojai]

User-facing changes

• Users now can select from multiple TTS services
• Improved providers management
• Ability to edit non-active providers
• We no longer validate provider API key on preferences. (We already have a robust error view in the provider loading, and validating api keys when the provider is not initiated is more complicated)

Main core changes

• Introduced new providers models.
• Providers subclassing improved. Better differentiation of class attrs and instance properties. Different base classes per engine.
• Providers format_ methods now return Soup.Message, giving more control of the request to the provider implementation
• Providers get_ methods now receive the data as bytes, giving more control on how to deal with the data
• Make custom implementations of Gio.ListModel to improve our data that interacts with widgets

TODO

• [x] Update search-provider if needed NO GOD! PLEASE NO!!! NOOOOOOOOOO
• [x] When setting the saved selected langs, check if are present in self.translator.languages.
• [x] Allow having empty recent langs
• [x] Exhaustive testing to prevent regressions before merging

[rafaelmardojai]

Current engine/feature status:

• Local: TTS
• Soup: Translation, TTS

I think we will implement the different engines per feature when we implement some consumer. That way we don't make unnecessary work.

[rafaelmardojai]

Open questions for discussion before merging:

• In providers/base I'm using python type annotation so we have some kind of documentation when implementing new providers. Should we start using it everywhere to improve code understanding for possible contributors?
• We have an inconsistent use of @Gtk.Template.Callback(). I'm using it on new code, but pieces of code moved in the refactoring are using the old way. If we decide to use it when possible, lets add some good comments in the callbacks definitions so it's clear from were that code is run.

@fushinari

[mufeedali]

Something is broken.

Regarding type annotation, I agree that we should be using it wherever possible. And about callbacks, wherever possible, we can have user-readable comments that still give us enough info to work with. For example: "window: Main Window (DialectApplicationWindow) -> Translate Button (translate_btn)"

[rafaelmardojai]

Something is broken.

Fixed, I was doing a really dumb thing there 😅

[mufeedali]

Looks good at first look, i'll be testing it once I get home today.

[rafaelmardojai]

The search provider has been updated. Should be ready to merge.

@fushinari Could you test if there's any major regression? If all is OK, I think we can merge and keep testing it on master branch.

[mufeedali]

There was a bug in the search provider but I've fixed it now. I couldn't notice any other regression in my testing.

As for my other commit, it's a fix for the "--text" parameter not working for LibreTranslate and Lingva. I found out that this is due to the language list not being loaded yet. Due to our asynchronous style of loading, the most reliable way for us seems to be the notify::visible-child-name signal and I've used the same.