DialogSet.Add: Unique dialog ids for name collisions but not for reference collisions

[carlosscastro]

Fixes #3913

The Add() method of DialogSet has a mechanism for supporting multiple dialogs with the same id, which is adding a unique suffix for internal book keeping.

There is a bug however, if the same exact dialog is added multiple times because it is referenced by multiple dialogs. In this scenario, this is not a name collision, we are just adding the same dialog. But still we are assigning a different Id and treating it as different which brings downstream incorrect behaviors.

The fix here is to more precisely detect whether this is a name collision, by checking whether the dialog that is being added, was already added. If that is the case, we don't assign a new id and just leave things as they are.

Note that this is not a declarative only bug or even an adaptive only bug. But in adaptive code, without declarative, something like the below would also fail without this fix:

var d1 = new AdaptiveDialog();
var d2 = new AdaptiveDialog();

Triggers = new List<OnCondition>()
{
    new OnIntent() 
    {
    	Intent = "i1",
      Actions = new Dialog[] {d1};
    },
    new OnIntent() 
    {
    	Intent = "i2",
      Actions = new Dialog[] {d2};
    },
    new OnIntent() 
    {
    	Intent = "i3",
      // eventually this will re-add d1 to the dialog set, and alter the id to 'd12'
      // Then when i1 triggers, it will look for d1 and not find it in the dialog set
      Actions = new Dialog[] {d1}; 
    }
}

In addition to the repro test, added another cancellation test to verify other scenraios where instances look the same but are expected to behave differently.

Did a quick performance analysis over 500 medium sized json files (500 lines) and saw no measurable difference in performance. The clone is as efficient as the previous deserialization so its a no change in net time spent loading resources.

[tomlm]

[tomlm]

I approve