Store osquery configuration and data per-registration

[RebeccaMahany]

Closes #1939.

Some osquery data, like the node key, should be stored per registration instead of globally. This PR updates how we store data for non-default registrations in our key-value stores. We will store this data by "identifier type" and "identifier" -- so, for example, the key nodeKey becomes nodeKey:registration:<registration-id>.

The data for the default registration will be stored just under the key (so, uuid, not uuid:registration:default) -- this should give us good backwards compatibility if launcher rolls back to a previous version, and means we won't have to do any data migration (from uuid to uuid:registration:default) to avoid e.g. a launcher re-enroll. This means that, since we only have the one default registration at the moment, the current data isn't actually being stored any differently!

A note about the KATC config: the KATC config store contains a series of key-value pairs, where the key is the table name and the value is the config for that table. Under this new storage scheme, the keys (for non-default registrations) would therefore take the form <table-name>:registration:<registration-id>. We treat the keys as such when retrieving the KATC config from bbolt. However, I am punting on setting the registration ID when setting the data in the KATC config store in bbolt to #1940 -- that will require figuring out how the control server wants to send down per-registration data to each subsystem, and I'm going to handle that in #1940 separately.

[zackattack01]

wondering if you think it would be worth it to return all parts here and let callers disregard/take what they need? not critical/blocking, just wondering if the identifier type gets additional uses if callers would want that

[zackattack01]

also fine with kicking that down the road I don't see much usage of this yet anyway

[RebeccaMahany]

Done!