Issue title: How are translations going to be handled for TextConst?
 Issue body: In reading about the new translation format (XLIFF, found [here](https://docs.microsoft.com/en-us/dynamics-nav/developer/devenv-work-with-translation-files)) I see: 
> As stated above, the ML properties (CaptionML, TooltipML etc.), the old report label syntax, and TextConst do not get included in the .xlf file and will not be translated. 

Does this mean something like this is still supported? 

`Constant : TextConst ENU='Check',ENC='Cheque';`
 Comments: 
 Comment 0: It's supported in a sense that it still does what it did (until we disable it completely). It will not get included in the xlifff file.
 Comment 1: How do we have translations on captions when that gets disabled? 
 Comment 2: @strophanthus you can use Labels with XLIFF files
 Comment 3: Ah, I see. thanks!
 Comment 4: @Gallimathias  I'm not sure I understand this answer in the context of replacing TextConstML.
Do you have an example of how would one use a Label as a replacement for multi-language and then use it in a scenario such as providing a multi-language error or message? 


 
 Comment 5: https://docs.microsoft.com/en-us/dynamics-nav/developer/devenv-work-with-translation-files
 Comment 6: @coffeecup007 No problem is quite simple, as you can see in the following example.

````VB
    procedure Test() 
    var
        test : Label 'this is a exampe text';
    begin
        Message(test);
    end;
````
 Comment 7: @DominikDitoIvosevic  thank you for the link, however I've already read it and it does not describe how to solve the problem of text consts, it only mentions " TextConst do not get included in the .xlf file and will not be translated."

@Gallimathias  thank you for the workaround.   Do you know if having a label variable is going to be the solution going forward to replace TextConst (and if so can we add a feature request to just have TextConst convert into the label), or if there is a different solution.    We're trying to decide if we should wait until the "real" solution, or if this is as good as it gets with respect to TextConstML.
 Comment 8: Thank you for a clear question @coffeecup007 .
Using labels is not a workaround, they are meant as a replacement for the TextConst approach. We are following the best practices of multilanguage development which all platforms are adopting and so we are separating the translation process from managing the source code.

That's why we are moving away from specifying actual translations in the source code and moving the translations into the xliff file. The most professional approach would be to not use even the label text from the source code as final text shown in the applications but to get an additional english to english proofreading and have the english xliff file for the english version. Of course, it all depends on the capacity and the development process of each company. This way your translators don't have to use source control of your application and can simply use the xliff file in one of the popular translation tools.

Use labels always going forward and move away from textconst as we will be dropping support for it.   The labels are meant to have developer comments, specify the length, specify whether the label should be translated at all and the text should be what the developer thinks would be a good text (which he might get proofread later). TextConst are an outdated model for translating and we are sunsetting it.
 Comment 9: Ok, thank you for the direction.   Can we convert this question into a feature request then (or bug? whatever is more fitting) to have the deprecated TextConst's be converted to report label controls in code.     It might be worth documenting in the previous given link that TextConsts should be converted to report labels and that this is intentional.   (As an outsider, not having insight into 'why', it seems counter-intuitive to have a UI control (the report label) supplant the equivalent of a text constant, and is not immediately obvious).       Ideally as part of that requested conversion (or in a different request), could we have a better process to generate the initial XLIFF file?  Perhaps as part of the txt2al or the export2newsyntax flag?   Or is there already another tool in the works? (i.e do we need to make such a tool ourselves, or will this bug/feature of text consts not being converted to their new report label equivalents be addressed soon? ).   Thanks!     
 Comment 10: They all get converted to their label syntax counterparts when using txt2al if you have only 1 language specified in them.
"report labels" are no the same thing as "labels". The multilanguage syntax was used in 3 places: variables, report labels and properties. The old syntax is called "multilanguage syntax" and the new syntax is called "label syntax". These 3 usages (variables, report labels and properties) get converted from the "multilanguage syntax" into "label syntax" when using txt2al.

Xliff files are generated if you put in the app.json file another field called "features" and a value "TranslationFile".
Like this:

{
    "id": "f4559cb0-b0aa-4f95-9d75-9775b2ac20e9",
    "name": "MyAlProject",
    "publisher": "Default publisher",
    "brief": "",
    "description": "",
    "version": "116.69.203.115",
    "compatibilityId": "116.69.203.115",
    "privacyStatement": "",
    "EULA": "",
    "help": "",
    "url": "",
    "logo": "",
    "capabilities": [],
    "dependencies": [],
    "screenshots": [],
    "platform": "116.69.203.115",
    "application": "116.69.203.115",
    "target": "Extension",
###     "features": "TranslationFile"
}
 Comment 11: Thank you @DominikDitoIvosevic  for replying ;)

 Comment 12: Thank you.  Yes, I'm aware of the 'TranslationFile' flag.  What I'm asking for is a better process to have the XLIFF generated with TextConst considered, perhaps as part of the txt2al tool, or the export2newsyntax, or something (powershell cmdlet? script? tool?) that is somehow accessible on the command line so that we can use it in build scripts.

The XLIFF generation doesn't seem to match with the requirement to only have one initial language in the original TextConst, or am I missing something.

In the current state this seems like the only way:
1) export2newsyntax
2) script to script extra language to work around txt2al gap/bug/missing-feature
3) txt2al 
4) script to fix gaps that txt2al doesn't handle.
5) alter app.json
6) build to get an xliff.
7) revert app.json so that xliff doesn't continuously get overwritten.
8) manually add in or script actual languages from step 1/2
9) build again.

Is there a better way?

Ideally txt2al would just generate the XLIFF as it goes, or as a stop-gap some way of doing this on the command line without having to alter an app package configuration file.

The context is conversion from old format to new format for existing apps and C/AL code.   The current tools and platform are not sufficient for this process without requiring substantial amounts of manual effort, I'm looking for ways to reduce man-hour effort and advocate for processes that drive towards this goal.

 Comment 13: 1. is your script in step 4 related to this issue?
2. your steps 5. and 6. are wrong. you should expect the xliff file to be constantly regenerated as you want it to be up to date with your AL source code. if you want to retain the file from a specific version of your code then simply rename the generated file so that you have 2 or more xliff files in the translation folder. the compiler collects all the xliff files from the Translations folder

there are 2 scenarios. 1 simple, 1 requiring some effort on your part.

1. scenario: you have only 1 language in your text consts.
-> you run txt2al and you get working al code which has labels instead of text consts. all your code is collected into the xliff file after you add the feature flag. you are supposed to copy the xliff file or rename it and add a target language to it. the generated xliff file is refreshed on each compilation so you should rename the file which you have added the translation to.


2. scenario: you have 2 or more languages in you text const.
-> here you're supposed to extract these translations into other files so that you can put them in the txt2al afterwards and remove them from the text const before you run txt2al. we have not provided a utility for this as it didn't get prioritized over other things were working on. after that you should have the same .txt file as in scenario 1 and you can continue with the scenario 1.
{'source': 'GithubIssues', 'repo_name_with_owner': 'Microsoft/AL', 'issue_id': 282205952, 'repo_stars': 366.0}