fix: allow users to provide String and Data values directly

[anitarua]

Addresses #82

The DataClient still uses the ScalarType enum internally, but the CacheClient provides public-facing methods that accept String and Data values directly. Requires overloading a bunch of functions (for example, set has 4 signatures now), but this was the most straightforward way I could think to implement this at the moment.

Removed the CacheClient protocol and DataClientProtocol extension along the way; I thought it would make more sense for the CacheClient to be its own separate public-facing interface rather than have its type be a union of the ControlClientProtocol and DataClientProtocol.

Open to suggestions / other ideas here though!

[pgautier404]

There is a lot of repeated code in these functions that I think you can factor out and DRY up quite a bit. For example, the get() methods could be simplified to each just take whatever key came in and wrap it in a ScalarType before calling an internal doGet() method that does all the actual work of validation, error handling, and calling dataClient.get(). I believe the same pattern should hold throughout the overloaded methods.

[pgautier404]

[anitarua]

protocol extension was re-added because default parameter values didn't work correctly in tests that expected CacheClientProtocol object instead of just CacheClient