Put the three providers in a table, and test the request rather than the list

Reworked on top of master. The Groq request itself needed nothing beyond a key,
a base URL and a model id, but two providers fit in an if and an else where
three do not, and each one was written out four times: in transcribe_target(),
in the key rows of the settings window, in save and in load.

config.TRANSCRIBERS holds them now, one row each: the name the user sees and
the three settings that keep its key, its endpoint and its model. The variable
an empty key falls back to is the name of its setting, shouted. The provider
box, save, load, `dikte models --provider` and `dikte test-key` all read that
table, so a fourth provider is a row and a default rather than a branch in five
files. The key field, its Test button and its answer line are built once and
the three signals became one that carries which key was asked about.

The tests moved into the files of the modules they cover and check what a
provider actually changes: that the request goes to api.groq.com with the right
model and fields, that the glossary now reaches everything except OpenRouter,
that a Groq error says Groq, and that the settings window carries the key and
the model there and back. GROQ_API_KEY is cleared for the test run like the
other two, so a developer who has one does not send a test to the network.

Co-authored-by: Muzaffer Emre <[email protected]>

CONTRIBUTING.md

@@ -79,10 +79,10 @@ next port breaks all of them.
 
 ## What a pull request should carry
 
-A change to behaviour comes with a test for it. Adding a provider means a test
-that the request goes to the right URL with the right fields; adding a platform
-means a test for whatever the parsing of its device list, clipboard or shortcuts
-looks like. Adding a setting means both halves of `settings_ui.py`: the round
+A change to behaviour comes with a test for it. Adding a provider means a row in
+`config.TRANSCRIBERS` and a test that the request goes to the right URL with the
+right fields; adding a platform means a test for whatever the parsing of its
+device list, clipboard or shortcuts looks like. Adding a setting means both halves of `settings_ui.py`: the round
 trip in `tests/test_ui.py` is what catches only one of them being written.
 
 Match the surrounding code: it is plain Python with no framework, comments