Provide additional mechanism for user context cache

[oklahomer]

Currently user context is stored in-memory with go-cache where key is the user ID and value is the function to be executed on next user input. This cache mechanism is easy to use, but has several pros and cons.

Pros

Cached values are stored in a simple map and its value type is interface{}. Since Go supports first-class functions, developer can simply put arbitrary function that satisfies func(context.Context, Input) (*CommandResponse, error) interface. This function can be built on-the-fly on user access and may contain local variables that were declared outside of its scope.

Cons

Since this is stored in process memory space, the cached user contexts can not be shared among multiple processes. This is vital when bot is running on multiple processes. e.g. Bot is serving HTTP server and is balanced over multiple servers. In most cases bot is running on single process as a "Client" to receive user inputs via HTTP streaming, WebSocket or other form of single connection. But some messenger platform sends user inputs via HTTP requests to bot server. To scale bot server architecture, bot may consists of multiple servers and hence cache must be shared over multiple processes.

---

To share cache over multiple processes, developer should be able to store cache in KVS such as Redis where key is the user id and value contains function id and function argument.