WIP: intent/slot training with separate datasets
If only intents are available, please use the text classification model. If only slots - token classification model. @ekmb the goal here is to train a single model capable of predicting both intents and slots, for use in the botmaker framework. We want users to be able to train the model even if they don't have intents and slots labeled in the same set of utterances. We don't want to force them to have two separate models.

To clarify: we are assuming the user has data with slots labeled AND data with intents labeled. The labels just might be for different sets of utterances. This pull request **introduces 8 alerts** when merging c7ee58244625478ca35462dddfe7a300326dde14 into ac79c2c6a5f50186bdcaceb9e72a8391271ce120 - [view on LGTM.com](https://lgtm.com/projects/g/NVIDIA/NeMo/rev/pr-2ca8db7e3dff8cdeb6c5991d077644b4945c5f04)

**new alerts:**

* 7 for Variable defined multiple times
* 1 for Unguarded next in generator Carol, I am not sure that it is needed from a practical point of view. Since usually you do not label slots separately from intents since they are usually related, no? This feature will make it much easier for users of the botmaker framework to create training data. They may not have intents and slots labeled at all, or may not have both labeled in the same data set. With this change, they can use existing data sets that have entities labeled and just label the intents in their own data (or vice-versa). Example: currently Zhen has created a data set for his bot with only intents labeled. We want to add slots, but we don't want to have to go through every single one of Zhen's utterances to label the slots. With this change we make a smaller training data set just for slots. This model is so widely used and I am afraid that any significant changes in it may have unforeseen effects. @carolmanderson let's discuss more offline your needs for training of this model. May be I can think on some alternative solution during data preparation or the opposite you will convince me that this model extension is necessary. @carolmanderson and @vladgets is this PR still WIP? I'll close it. I haven't had time to work on it lately and I think we may end up trying a different approach. 
Requesting early feedback on the approach. 

The purpose of these changes is to allow the joint intent/slot model to be trained on data where only slots are labeled or only intents are labeled. 

* Users can supply _up to_ three labeled data sets: one with only slots labeled, one with only intents labeled, and one with both slots and intents labeled
* Separate Dataset objects are created for each of the above
* A custom Sampler tells the training Dataloader which examples to put into each minibatch
* Each minibatch draws from only one data source. When the loss is calculated, intent loss is set to zeroes if no intent labels are supplied; slot loss is set to zeroes if no slot labels are supplied. This is controlled by a data type indicator variable passed from the data loader. 


I initially implemented these changes in a subclass of the existing intent/slot model (as well as the dataset and data descriptor classes), but it seems like that will create an extra burden to maintain two model classes that do essentially the same thing. So now I've made the changes directly in the existing model.
