Move CrossTrainRecognizer generation logic from lubuild/qnabuild to crosstrain

[luhan2017]

we hit some issue when enable qna and crosstrain recognizer in composer. So I propose to have a more clear design of the functionality of each lib. We should not put the crosstrain recognizer logic in qnabuild or lubuild, what if non-composer users and they don't care about crosstrain? I think crosstrain recognizer genration logic should be in crosstrain library.

The whole crosstrain + lubuild + qnabuild process should look like this.

1. composer will call crosstrain api.
   Here is the crosstrain logic.
   if .lu and .qna are both empty. do nothing, and just generate a CrossTrainedRecognizer with no recognizers inside.
   if only .lu not empty. crosstrain on lu only, and generate a crosstrainedrecognizer with lu recognizer only.
   if only .qna not empty. no need crosstrain, and generate a crosstrainedrecognzier with qna recognizer only.
   if both not empty, crosstrain them, and generate a crosstrained recognizer with both lu and qna.

lubuild don't care qna, qnabuild don't care lu.
they just take the .lu files or .qna files if files are not empty, prompt for keys and generate the multilanuage luis/qna recognizer.

@vishwacsena, @boydc2014 thoughts?

[feich-ms]

I don't think it's necessary to move CrossTrainRecognizer generation logic to crosstrain library. It will confuse users if we have CrosstTrainedRecognizer and other recogizers generated in different library. I prefer to optimize the lu/qnamaker build apis to provide a function for users to generate empty crosstrained recognizer when both .lu and .qna are empty files. Currently I have three functions exposed in builder.ts. The flow to use them are:

loadContents() => load lu files and generate empty recognizers including single recognizer, multi language recognizer and crosstrained recognizer

build() => load lu contens and all empty recognizers from loadContents() and fill the recognizers with appid/kbid and other information after luis/qnamaker published, and then generate all contents that need to write out ot print

writeDialogAssets() => write recognizers and settings contents generated from build() function

I think for .lu and .qna are both empty scenario, we can use loadContents() to return empty crosstrained recognizer and directly call writeDialogAssets() to write empty crosstrained recognizer only. My detail proposal is like:

1. lubuild and qnabuild expose a function to see if all files are empty(here empty means no intent and entity for resolved lu file and no QA pair for resolved qna file)

2. handle flow based on different conditions:
   .lu and .qna are both empty => no crosstrain, and just generate a CrossTrainedRecognizer with no recognizers inside. The flow is
   lu: loadContents() -> writeDialogAssets()

   only .lu not empty => crosstrain on lu only, and generate a crosstrainedrecognizer with lu recognizer only. The flow is
   crosstrain: lu files
   lu(crosstrained): loadContents() -> build() -> writeDialogAssets()

   only .qna not empty => no crosstrain, and generate a crosstrainedrecognzier with qna recognizer only. The flow is:
   qna: loadContents() -> build() -> writeDialogAssets()

   both not empty => crosstrain them, and generate a crosstrained recognizer with both lu and qna. The flow is:
   crosstrain: lu and qna files
   lu(crosstrained): loadContents() -> build() -> writeDialogAssets()
   qna(crosstrained): loadContents() -> build() -> writeDialogAssets()

[feich-ms]

Fixed in PR #889