dcr: BotStateManager should be split into separate ConversationState and UserState middleware

Currently we have a single BotStateManager middleware that’s responsible for reading & writing both conversation state and user state. I’d like to propose that we replace this with two separate pieces of middleware that have logic for managing conversation state and user state independently. The reasoning for that is:

• You may want to use one but not the other and while we have config switches to turn off either piece of state it would be clearer if they were separate middleware.
• You may want to use a RedisStorage provider for storing conversation state and a separate AzureTableStorage provider for user state. Again, we can handle this through configuration but it’s cleaner if they’re separate middleware.
• Tracking conversation state needs slightly different semantics then tracking user state. This is the bigger reason for separating the two. With conversation state if you see an “endOfConversation” activity sent or received you should delete the current conversation state. This is needed to prevent Conrtana skills from getting into a stuck state but is generally just a good way to help your bot avoid stuck states.
• Key value storage is fine for tracking conversation state but user state is probably better tracked as a graph so in production systems it seems likely that you’d rarely want our key-value based user state manager.

The con to splitting these up is that should you want to run both you now have to read them in series. I have another proposal to create a ParallelMiddlewareSet which would address that as there are plenty of other things you’d want to do in parallel in a production bot.

[Stevenic]

@cleemullins is rocking 😃 I have some catching up to do… lol

[cleemullins]

Closing, since PR #159 is merged.