fix: support URL-encoded form data in qBittorrent add endpoint

[calmcacil]

Sonarr/Radarr send application/x-www-form-urlencoded (not multipart/form-data) when adding magnet links via the qBittorrent API. The handler unconditionally calls r.ParseMultipartForm() which returns a 400 Bad Request when the Content-Type is URL-encoded.

Check Content-Type at the top of the handler and fall back to r.ParseForm() when the request is not multipart. The existing r.PostFormValue() calls and the if r.MultipartForm != nil guard for file uploads are compatible with both parsers.

Closes #1

[calmcacil]

Tested on my local system with Sonarr sending magnet links. Both multipart (file uploads) and URL-encoded (magnet links) content types are handled correctly.

[MrJoiny]

Looks good to me.
We could use mime.ParseMediaType from the std lib https://pkg.go.dev/mime#ParseMediaType to cover cases where the Multipart/Form-Data is uppercase. This would be unlikely to happen from Sonarr/Radarr.
What do you think about that? Otherwise I would just merge it and #4 after that.

[calmcacil]

Sounds good — mime.ParseMediaType is the more robust way to read the header anyway, so I've applied it. I also rebased #4 onto the updated #2 branch so it doesn't accidentally revert the Content-Type change when both get merged.