fix(xp-treatment): Add field tags to poller configs and make XP plugin pass poller configs

[deadlycoconuts]

What this PR does / why we need it:
In PR #87, a new XP Management Service poller was introduced to the XP Treatment Service. Unfortunately, this feature is not usable within the XP plugin for a couple of reasons, which this PR seeks to address:

• the ManagementServicePollerConfig config struct required for this feature lacks the necessary field tags (json) to parse configs from the config file into actual values in Go
  • FIX: addition of json tags to the fields of ManagementServicePollerConfig
• the ManagementServicePollerConfig.PollInterval field is of the time.Duration type, which doesn't allow yaml/json values (this is how the XP configs are configured, passed between various components) to be easily parsed into valid time.Duration values
  • FIX: changing of the PollInterval field to the int data type
• the XP plugin isn't modified to pass the poller configs from the plugin manager to the plugin runner
  • FIX: addition of a new ManagementServicePollerConfig field to the plugin config struct TreatmentServicePluginConfig which needs to be configured on the Turing API server (this config gets passed to the XP plugin whenever a Turing router is deployed)
• the XP runner plugin is unable to start the poller because the poller is only turned on within an instance of Server, which isn't initialised/used within the XP runner plugin
  • FIX: refactoring of the Poller object of the server package into a PollerService of the services package that gets initialised and started up in both the XP Treatment Service and XP plugin runner

Additional Changes to the XP Plugin
This PR also updates the way the XP plugin manager retrieves the MessageQueueConfig (and then passes it to the XP plugin runner). Previously this config is retrieved from the XP Management service, which strongly couples the way the Management Service publishes experiment updates with the way the XP plugin runner retrieves these updates i.e. if the XP Management Service uses PubSub to publish updates, the XP plugin runner MUST also use PubSub to receive those updates.

With this new change, the MessageQueueConfig must now be specified explicitly as part of the XP plugin manager configs (specified in the Turing API server's experiment engine configs). This allows the XP plugin to receive experiment updates in a way that's independent of the XP Management Service e.g. routers using the XP plugin can use the new poller service to retrieve updates from the Management Service even while the Management Service continues to publish updates to PubSub (presumably for other XP plugins/Treatment Service instances to receive updates via PubSub).

Note that the current implementation DOES NOT clean up the XP Management Service to stop serving the MessageQueueConfig via one of its API endpoints. This will be done at a later time to clean up its current implementation.

cc @rautelaanirudh

Which issue(s) this PR fixes:
See above

[deadlycoconuts]

Thanks a lot for the review! :D Merging this now! 🚀