Lay foundation for VSIX localization and re-enable Single-project MSIX Packaging templates

[evelynwu-msft]

There are two major, somewhat intertwined, changes in this PR:

Lay foundation for VSIX localization

There is an undocumented method for localizing string resources in VS project and item templates. Firstly, the extension containing the templates must provide a VSPackage. Next, a VSPackage.resx (Visual Studio first looks for the VSPackage resource stream) is added to the extension project to hold the string resources; the IDs of these resources must be integers (specifically, within the range of a unsigned int). Finally, the Name and Description elements in each .vstemplate's <TemplateData> section so that:

1. They do not provide a text value
2. The Package attribute is the GUID assigned to the extension's VSPackage
3. The ID attribute is the ID of the string resource as defined in the .resx

The convention that we will use for choosing resource IDs is as follows:

1. Numbering starts at 1000. This gives us what should be a sufficient number of digits to work around the VS's .resx designer use of a lexical sort.
2. If an ID N is even (e.g. 1004) then it is the default resource ID, and N+1 (e.g. 1005) is the resource ID to be used when we are creating an experimental VSIX.

A consequence of the above is that we now have an assembly that ships with the extension and therefore must have separate versions for Dev16 and Dev17. We thus now have a total of four VSIXs: C++ Dev16, C++ Dev17, C# Dev16, C# Dev17.

This change also refactors how we perform our .vstemplate/source.extension.vsixmanifest edits. Previously, we were using a combination of XmlPeek and XmlPoke tasks to modify them in-place early in the build; an unfortunate side-effect was that when loading the extension solution in Visual Studio, the targets responsible for restoring those files at the end of the build would often not run, resulting in a repo polluted with undesired changes. Worse, because each template is built independently by its own project which is then referenced by the actual extension project, there was no way to update each .vstemplate with the correct package GUID (since each template is included in two different extensions, each with its own package GUID). Therefore, it was necessary to move the rewriting step to later in the build, right before the VSIX container is built from the intermediate output. This allows the correct edits to be made while also increasing the reliability of the build (since we are now modifying the intermediate outputs rather than the source files). Finally, the rewriting of the .vstemplates was simplified by switching to an XSL transformation; source.extension.vsixmanifest continues to be modified using XmlPeek/XmlPoke because switching it to use an XSL transformation was a) unnecessary, and b) out of scope.

Re-enable Single-project MSIX Packaging project templates

The Visual Studio Marketplace backend error that required us to pull out the Single-project MSIX Packaging project templates at the last minute prior to the 1.0 Experimental release has resolved itself, thereby allowing us to re-enable the templates for the upcoming 1.0 Preview release. In addition to promoting the templates out of the "experimental" feature set, the extension pack has been updated to be compatible with both Dev16 and Dev17.

[evelynwu-msft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[evelynwu-msft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[evelynwu-msft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[evelynwu-msft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).