feat: added preliminary SDK support to "rand_data" plugin

[patrickjcasey]

This pull request is the first pass at using the hipcheck-sdk crate to make a plugin for hipcheck

The goal of the SDK is to make it as easy as possible for plugin authors to write new plugins for hipcheck!

The hidden hc plugin command no accepts another flag --sdk that will use the dummy_rand_data_sdk plugin, rather than the dummy_rand_data plugin

There are some outstanding issues that still need to be addressed, whether in this issue, or in another issue in the future:

• How are we handling third-party dependencies that are exposed in public facing types (serde_json::Value, schemars::schema::SchemaObject, ...)
• How much documentation should be present in the hipcheck-sdk crate
• How do we test the hipcheck-sdk crate to ensure it is producing the desired behaviors and integrates cleanly with what hipcheck is expecting
• Does it make sense to add a prelude module so a user would be able to use hipcheck_sdk::prelude::* and have the most common imports?

[alilleybrinker]

Thanks @patrickjcasey! I'll take a look tomorrow! 😄

[j-lanson]

Re: a prelude crate

As far as I see, excluding the re-exports the only types users need access to is QuerySchema, DynQuery, NamedQuery, Query, Plugin, PluginServer, PluginEngine, plus the error module. And anyone using the SDK to write a plugin will need all of these.

I'd be in favor of adding a prelude crate so that users that want to do so can simply import * as you have shown above.

Leave this and the reexport crate as a separate commit on top for now in case we need to walk it back

[j-lanson]

As for documentation and testing, those are important, but they can be done after the SDK is merged

[alilleybrinker]

I concur on the idea of a prelude module.

[j-lanson]

This looks good to me! Great work