In-memory key value store

[GuessWhoSamFoo]

Describe the problem/challenge you have
Plugin authors currently have to maintain storage of data on their own such as caching responses of API calls. An addition of a key value store available to plugins allow developers to store data from Print, Navigation, or Service requests.

Plugins can also theoretically share data through such an API although this likely would not be implemented in an initial pass.

Describe the solution you'd like
Octant can provide an in-memory key-value store to hold arbitrary metadata. Each key can be associated with metadata such as an expiry time and some ID for each running plugin.

A series of methods can be exposed to represent typical CRUD operations:

request.DashClient.Set - adds a new key value pair with a default expiry time, if any
request.DashClient.Get - returns value for a given key, returns nil if key does not exist
request.DashClient.List - lists all keys
request.DashClient.Delete - deletes a key value pair

A watcher can can the key value store for expired pairs and cleans up every N interval. The API can be adjusted to only return non-expired values initially. Additionally, there would have to be an upper bound on the number of keys that Octant can store in order to prevent OOM errors as this feature is intended to improve developer experience rather than replace more robust libraries for persisting data in memory.

[wwitzel3]

This has been mentioned before and I'm not a fan of this. I think it introduces a lot of burden for not a lot of value. This is a documentation/example problem. This can be solved by convention.

We can document a pattern of how to do this for both Go and JavaScript without having to be the owners of the store. Authors could use something like https://github.com/patrickmn/go-cache OR https://github.com/ptarjan/node-cache

I consider this a duplicate of #557 and I'm going to move this to be a discussion.