launcher should be able to run between 0 and n osquery instances

[RebeccaMahany]

We want launcher to be able to run with between 0 and n osquery instances:

1. When launcher can't start osquery, we don't want to restart launcher altogether. This is because, in the case where the current osquery instance is old and not compatible with the current database, it can be helpful for launcher to run for a while with 0 osquery instances so that launcher can reach the autoupdate cycle and self-update its osquery version.
2. In the short term, we want to be able to split up where Kolide queries run versus where tenant queries run, so that if a tenant creates a query that causes issues with osquery, the Kolide queries will still run. (This amounts to running 2 osquery instances.)
3. In the longer term, we want to support multitenant installations. This will mean 1 osquery instance for Kolide queries, and 1 osquery instance per tenant. I propose we refer to these consistently as "Kolide osquery instance" and "tenant osquery instances".

There are a couple steps we need to take to be able to do this. This issue tracks the foundational steps necessary to run 0 or 1 osquery instances:

• When the osquery runner cannot launch an osquery instance, do not return an error. Instead, retry launching osquery instances (maybe with a bit of backoff?). We should tackle this issue first and earlier, to handle the edge case noted in 1 above. We could also consider terminating the autoupdate delay in this case, to download a new osquery version quicker. Could also potentially tackle the item below ("Make the osquery instance status available in knapsack") at the same time, if easier.
• Make the osquery instance status available in the knapsack. We will probably want to add it to the status blob returned by localserver.
• Store osquery data (node key, uuid, config, keys, ATC config, KATC config) in bbolt and in sqlite per-organization as well as globally. (We want to keep storing globally because this change must be backwards compatible.) To start, store everything under the current tenant. We may want to key off the node key, or a "registration ID" that doesn't yet exist in K2; we don't want to key off munemo in case we end up wanting multiple instances per single tenant.
• Split up how we store and set flags that are per-tenant instead of per-device. These are potentially limited just to osquery flags and osquery watchdog flags (enabled, memory limit, utilization limit, delay). This change must be backwards compatible.
• Refactor osquery runner to manage running multiple osquery instances (one Kolide, and a variable number of tenant osquery instances). Are we able to set enough information on the extension manager server to be able to identify at the extension level which instance the request is coming from? If not, we need to have an extension per instance as well.