Fix wrong id_for_label usage in rendered evaluation edit form

[richardebeling]

Fixes #1769.

Our old code was broken and just happened to work accidentally before django 4: The default widget for a choice field is a Select widget. With that, the rendering:

<select id="test" name="test">
   <option>1</option>
   <option>2</option>
</select>

wouldn't require any id_for_label to be set for the individual values. However, before django 4, this happened to be set, and our code relied on that with no documented guarantee.

This PR changes the button groups to use RadioSelect widgets, which would be rendered as:

<input type="radio" id="id_1" name="test" value="1"><label for="id_1">1</label>
<input type="radio" id="id_2" name="test" value="2"><label for="id_2">2</label>

i.e. here, every choice gets a seperate ID. This is also guaranteed by the docs:

To get more granular, you can use each radio button’s tag, choice_label and id_for_label attributes

So this time, if anything changes, we should see an entry in the release notes.

Edit: We can probably make a front end test for this one, it should be detectable just from the rendered html

[janno42]

Do you want to add a test? (:

[niklasmohrin]

This seems all correct, blocking until test though (as discussed in person)

[niklasmohrin]

Take this:

const formData = await page.evaluate(() => {
    return Object.fromEntries(new FormData(document.getElementById("evaluation-form") as HTMLFormElement));
});

[richardebeling]

Take this:

const formData = await page.evaluate(() => {
    return Object.fromEntries(new FormData(document.getElementById("evaluation-form") as HTMLFormElement));
});

Nice, thanks. Added that, seems to work now.

I've removed the TomSelectedHtmlSelectElement interface, because I figured it doesn't really help if we add "This has a .tomselect attribute" to the type system, but then go on to do stuff inside there (-> .tomselect.options, access its keys, ...) while only having it declared as any. Or, to say it differently: That only hid the any behind another interface, but didn't make the code type-safe. I think if we want proper typing, we should just use the proper tomselect types.

---

Codacy complains about magic numbers (in a test, I think they are fine: We do want to click the first button that says "xyz") and any / non-null-assertions (Also fine for me: Its a test, I'm fine if it breaks at runtime, I don't want to write additional boilerplate code just to make that explicit.)