feat #6: Track number of requests per user agent

[MarcusRiemer]

This is a first example on how working with one large table could look like when tracking user agents. Notable things from the top of my head:

• I somewhat attempted to make the new columns optional. If someone doesn't run the migration but updates to this version, everything should work as it did before. But I wouldn't know how this could be properly tested.
• Making user agent tracking optional was a little bit annoying for the Redis queuing that I missed initially, as I don't use it. I took the liberty to refactor the serialization and deserialization of such keys but didn't include any migration path because I have no idea how to test this properly. So users would need to drain the queue as part of the migration. I guess this could be salvaged by checking whether the key is in the old format if this feels important.
• Customization of extracted strings is hinted at, but not yet implemented. But this should be mainly a documentation issue, as the code is technically only missing a setter.
• I bumped the minimum Rails version to 6 in order to use SQL upserts. This should be more performant and more secure (for whatever security is needed to track single visits, but hey). This however has an important implication: As in SQL NULL is not equal to NULL the upsert will only work if all columns have empty strings as default. This is not yet reflected in the migration.
• I didn't touch the UI for the moment.