Figure out how to build / load / combine plugins

[Zepheus]

Right now, there is a PluginPack that registers a single binary (.so) for different purposes.
We need to figure out:

• How to separate each part into a separate binary. E.g. I'd like to use Prometheus for logging and ElasticSearch for tracing. It should allow combinations flexibly.
• How to build plugins in open source. Should we have a sub-directory? Separate cmake files for each? Separate repositories?

[sh00s]

For the first part, I propose to transform the PluginPack into something with the following interface:

// All plugins will have to derive from this class. The implementation has to
// ensure that calls to all methods are thread-safe
class Plugin {
 public:
  enum class Type {
    PLUGIN_COLLECTION = 0,
    CONFIG_SOURCE = 1,
    STATS_PUBLISHER = 2,
    TRACE_LOGGER = 3,
    ...
  };
  // Specifies the type this plugin belongs to.
  virtual Type type() const = 0;

  // Returns the identifier for this plugin. This can be used to:
  // 1) load multiple plugins of the same type and pick which one to use
  //    via configuration / settings, and
  // 2) have per-plugin configuration.
  // Identifiers should be unique for all plugins loaded.
  virtual std::string identifier() const = 0;

  // A string that we can log somewhere when using this plugin.
  virtual std::string displayName() const = 0;

  // Versioning information
  virtual std::string version() const = 0;

  // If per-plugin configuration is present in the config, it would be fed to the
  // plugin immediately after initialization and on every config update.
  void onConfigUpdated(folly::dynamic plugin_configuration) = 0;
};

// A helper that would be returned by a `load_plugin()` function to ease loading several
// plugins at once from a single library
class PluginCollection : public Plugin {
 public:
  Type type() override {
    return Type::PLUGIN_COLLECTION;
  }
  virtual std::vector<std::unique_ptr<Plugin>> getPlugins() = 0;
};

Then we'd have classes that derive from the Plugin class to implement each of the plugin types - e.g. TraceLoggerPlugin, ConfigSourcePlugin, etc. Each implementation would then have to derive from these.

This is off the top of my head, so suggestions for improvement are welcome.

[sh00s]

Separated #56 and #57 out of this

[sh00s]

This is mostly done. I added documentation in 84fbb0a to explain how to write new plugins, and filed the follow-ups mentioned above for the remaining parts.