Review switching to using Xliff tasks for localization

[mrlacey]

See if switching will make managing localized files easier

See https://github.com/dotnet/xliff-tasks X-Ref https://github.com/github/VisualStudio/pull/1933

Need to change:

• [ ] Resources/StringRes.resx
• [ ] RapidXamlPackage.vsct
• [ ] VSPackage.resx
• [ ] LocalizationHelper

[mrlacey]

Do this for VSCT files only (at least initially)

Note that this will impact build scripts that customize names for different build versions

[mrlacey]

As build script will now append a bracketed item to the end of some entries for some build scenarios, the localization tool & Resourcecs.resx file should also be updated appropriately.

[mrlacey]

Started exploring this in https://github.com/Microsoft/Rapid-XAML-Toolkit/tree/Issue82-XliffTasks

Will be a very big change and there are currently some blockers as it's all or nothing

[mrlacey]

For reference, see also https://github.com/jcansdale/LocalizeVsix

[mrlacey]

Moving back to BackLog. After a week of investigating this, I'm giving up.

• Issues come from a combination of needing default and en-US translations to keep all projects happy.
• Having resource files in different locations also confuses xlifftasks.
• Localizing multiple resx files causes somewhat of a problem.
• I've also been unable to get dynamically created menutext to localize correctly. It's a combination of trying to address all these problems at once when the process isn't very clear, debugging issues is very hard, and the vsct files are turned into a binary format which makes them hard to check in the generated libraries.

May review this again in the future as it would be nice to tidy up the project somewhat and remove the need for customized loc file manipulation.