Task: Cleanup database installation process

## 1) [Resolved] Ensure table truly exists

Problem: Somebody may duplicate the options table while creating a new subsite locally for example, but for some reason not copy over the cron control table. As a result, the `a8c_cron_control_db_version` option is set but the table doesn't exist - and will never be attempted to be created. So you end up with perpetual errors until manually resolved.

Solution: Not 100% sure, kind of tricky. This would be an ideal for a cron job to verify the table exists, maybe in an existing internal cleanup job. But uhh, cron is broken if the table isn't there. So maybe need to do a SQL query to just check that the table truly exists every once in a while? Alternatively, try to leave cron in a functional state when this happens - but that may be hard.

____

## 2) [Resolved] Cleanup overall table creation flows

There are lots of different flows for when/how a table is created, might be good to simplify a bit where possible. Of note, `wpmu_new_blog` is a deprecated hook that needs to be updated a minimum.

Also when the table doesn't exist yet, we just skip over the WP filters for that request. Maybe this is still ideal, but it does cause for some hacky flows in unit testing.

____

## 3) Prepare for schema changes

The plugin won't currently react very well to just incrementing the db_version option if we ever do schema updates, as it won't actually update itself.

Notably eying changing the `ts_action_instance_status` index to be re-ordered to `action` -> `instance` -> `timestamp` -> `status` instead allowing it to be used for action-only queries as well (which WP core has a few of).