Q# should include decompositions to alternate quantum gate sets

[swernli]

Q# defines the set of basic gate operations in the Microsoft.Quantum.Intrinsic namespace, where the fundamental operations are implemented as body intrinsic and other operations are expressed as decompositions onto these body-intrinsic operations. These effectively represent a specific quantum gate set that the current version of the simulator implements. To facilitate experimentation, testing, and eventually targeting of simulators and hardware with a different quantum gate set, the runtime should have infrastructure and examples of alternate implementations of operations in the Microsoft.Quantum.Intrinsic namespace as decompositions on top of the body-intrinsic operations for that alternate gate set.

Introducing this functionality will require several tasks.

• Refactor Qsharp.Core into the foundational elements shared by all decompositions and the replaceable elements that are override by alternate decompositions. (Resolved by Refactor QSharp.Core into Foundation + Core #254)

• Introduce the first new decomposition package on top of a different quantum gate set with alternate implementations for Microsoft.Quantum.Intrinsic operations. (Resolved by Adding Type2 targeting package and tests #363)

• Allow alternate decompositions to be tested against the default QuantumSimulator to verify behavior. (Resolved by Adding Type2 targeting package and tests #363)

• Refactor the EntryPointDriver to allow for target specific simulators. (Moved out to issue Refactor EntryPointDriver to not compile against a specific simulator #388)

• Fix e2e build to allow integration of refactored QsharpCore into main (Return projects to original paths to fix e2e build #397, Updates/fixes to decomposition feature branch #414)

• Add decomposition packages for other common quantum gate sets. (Resolved by Add Type1 target package and simulator support #367)

• Add documentation on individual decomposition packages and general guidance on authoring new packages.

• Rework use of internal in defining callabes that can be implemented outside of their original binary (see discussion in Add Type1 target package and simulator support #367). (Moved out to issue Rework use of internal to allow defining of callabes that are not part of public API but implemented outside of original binary #389)