Add Readarr Trigger

[rg9400]

First rough attempt at adding a Readarr trigger using Lidarr's trigger as a base. Additional events for Lidarr/Readarr pending until OnDelete is merged with both of them (Rename + OnDelete both pending)

[m-rots]

Unfortunately this PR still ages from before Autoscan's router was overhauled. We would still like to see this merged though.

However, as it stands, all -arr triggers are built on top of the old trigger architecture. Unlike A-Train, which is the sole trigger that makes use of the new architecture. So the question becomes: do we keep Readarr inline with the other -arrs or do we switch it over to the new architecture, as we do not have to account for backward compatibility? @l3uddz

[m-rots]

Whoops, still mentions Lidarr

[l3uddz]

I think it makes sense to have the comments fixed and then merge this.

At which point; we can refactor all the triggers to be in line with the new architecture as a separate PR?

[m-rots]

So I'm afraid that bridging all triggers to the new architecture is a breaking change.

A-Train accepts /a-train/{drive-id} routes. However, the -arr triggers essentially match at the root: /{name}. Funnily enough, you can thus call your Sonarr trigger radarr and everything would work just fine.

Bridging the triggers to the new architecture would force us to use /{trigger name}/{id} across the board. However, this would require users to update their -arr installs to point from /sonarr to e.g. /sonarr/sonarr.

But I'm not keen on the route having sonarr in there twice. Ideally, /sonarr would resolve to some default sonarr config option and users would write 4k as the name in their config instead of sonarr-4k, so the path would become /sonarr/4k.

We could write a migration script for this to get away with introducing a breaking change though.

[m-rots]

Closing in favour of #174. Thanks for the initial groundwork @rg9400 :)