Create hierachical packages for some collections to better abstract

[szul]

As discussed with @iMicknl, and noted in #63, we should take packages like the adapters and storage and break them out more, but leave the top level one for "install all" capabilities.

I like how Text Recognizers are handled.

For storage, it could be:
npm install @botbuildercommunity/storage for the suite and...
npm install @botbuildercommunity/storage-ats to get just the Azure Table Storage.

For adapters, it could be:
npm install @botbuildercommunity/adapters for the suite and...
npm install @botbuildercommunity/adapters-console to get just the console adapter.

Open to thoughts/suggestions.

[iMicknl]

I just had a second thought about this, for the adapters. If we want to achieve something like this, all interfaces and classes should be unique.. This can be easily achieved in the recognizers-text repository, since all packages are related and inherit the same interfaces. I belief this will be different in our situation.

Is there a real use case to use @botbuildercommunity/adapters and @botbuildercommunity/storage? I would be in favour of deprecating those packages and just have people reference the specific package. Not many people are gonna use multiple adapters or storage implementations in a single project.

Maybe we can conclude a naming strategy and bump all packages to 1.0.0? Like the dotnet repo has.

[szul]

I get that in production you're likely to choose one adapter or one storage, but from a training, tutorial, and education perspective, it is more convenient for me (and other who do tutorials), just to be able to install one package (such as adapters), and then experiment with each--so I don't see the harm is keep a base "suite" to "install all" for situations like those.

I'm open to ideas though.

[iMicknl]

Valid point. In that case interfaces / classes should be unique in the adapter 'namespace' for example, so that would be something to keep an eye on.

[szul]

I'm starting to reconsider a base package. I built the text analysis middleware (PR #70) to be swappable, so whether you use Cognitive Services or IBM Watson, the class names are the same. If we had a base middleware, it would create namespace collisions. Fixing those collisions would basically end up losing the value of having a base install package to begin with.

Open to suggestions. If we kill the idea of a base package, we'll just have to rename the adapters to the console adapter namespace, and then rename the storage to something for ATS.