Add sqlite cleanup functionality

[brunnre8]

Once this is getting hooked up, it'll periodically delete old
messages.

The StoragePolicy can be chosen by the user, currently there's
two versions, delete everything based on age is the obvious.

The other is for the data hoarders among us. It'll only delete
message types which can be considered low value... Types with
a time aspect like away / back... joins / parts etc.

It tries to do that in a sensible way, so that we don't block
all other db writers that are ongoing.
The "periodically" interval is by design not exposed to the user.

Fixes: #2822

[brunnre8]

This does not yet contain a way for a client to make the storage policy more stringent (meaning, delete more aggressively).
That is a feature we could easily add though, given the structure of it.

For now, that should be the bare minimum so people can finally turn their cronjobs off that manually mess with the db

[brunnre8]

query example, for statusOnly:

delete from messages where id in (
    select id from messages where
    time <= 1698515398915
    and type in ('away','back','invite','join','kick','mode','mode_channel','mode_user','nick','part','quit','ctcp','ctcp_request','chghost','topic','topic_set_by')
    order by time asc
    limit 200
)

Now, this seems to drive up the cpu to 100% for quite a while on every cleaning cycle.

sqlite uses the time index, but the string comparison of the types is... bad.

We can create a new index for messages, on type.
That seems to get rid of the CPU spikes, using more storage and ignoring the time index.

Alternatively we can also stop sorting, we don't really need it. It's just a bit easier for the user to understand, when messages are deleted in order, so that they don't have funny holes in conversations when the max age is very low (say a day)

[brunnre8]

This is now running on my live instance, with the added index:

CREATE INDEX msg_type_idx on messages (type);