Submodule MonoTouch.Dialog, so that we can easily build it using .NET. This
submodule will become redundant when/if we publish a .NET version of
MonoTouch.Dialog, but until that happens we need it at least for our own test
suites.

This also means we have to copy our NuGet.config and global.json files to the
MonoTouch.Dialog project directory so that we point msbuild to use our local
build.

New commits in spouliot/Touch.Unit:

* xamarin/Touch.Unit@cbda703 [Touch.Client] Use MonoTouch.Dialog from a submodule. (dotnet#109)

Diff: https://github.com/spouliot/Touch.Unit/compare/3345db2f4e6408fdf2e8f099251c5c1310b56937..cbda70358360329854ea399100a2b5b04ae43982

* Submodule MonoTouch.Dialog.

Submodule MonoTouch.Dialog, so that we can easily build it using .NET. This
submodule will become redundant when/if we publish a .NET version of
MonoTouch.Dialog, but until that happens we need it at least for our own test
suites.

This also means we have to copy our NuGet.config and global.json files to the
MonoTouch.Dialog project directory so that we point msbuild to use our local
build.

New commits in spouliot/Touch.Unit:

* xamarin/Touch.Unit@cbda703 [Touch.Client] Use MonoTouch.Dialog from a submodule. (#109)

Diff: https://github.com/spouliot/Touch.Unit/compare/3345db2f4e6408fdf2e8f099251c5c1310b56937..cbda70358360329854ea399100a2b5b04ae43982

* Use relative path for submodule.

And fix indentation and set the branch name.

* Don't use 'RootTestsDirectory' when it might not be defined yet.

* [tests] Our test projects don't need to reference MonoTouch.Dialog directly.

The projects get the MonoTouch.Dialog reference indirectly through the
Touch.Client project reference.

* [tests] Only validate unique errors in the .NET unit tests.

* [tests] No need to reference System.Json anymore, that's handled directly in the MonoTouch.Dialog project.

* [tests] Reference nunit.framework.targets so we get a workaround for an NUnit issue everywhere.

* [msbuild] Only try to create a package if we're able to create an app bundle.

This fixes an issue where a library project would try (and fail) to create a
package when 'CreatePackage=true' (which could be set for the executable
project, but inherited by the library project since the executable project
depends on it).

* [tests] Adjust PackTest.BindingXcFrameworksProject to not set the AssemblyName property.

MSBuild ends up being very confused when the project we're trying to build
depends on other projects, because AssemblyName is set for all the projects
being build, and MSBuild complains about ambiguous projects:

> error: Ambiguous project name 'bindings-xcframework-test'