[CMD] CALL: Fix the implementation of the CALL command, make it more compatible with Windows' CMD.

- Fail if no parameter is provided.

- The "CALL :label args..." syntax is available only when command extensions
  are enabled. Fail if this syntax is used outside of a batch context.

- Reparse the CALL command parameter with the command parser, in order
  to accurately parse and interpret it as a possible command (including
  escape carets, etc...) and not duplicate the logic.
  ** CURRENT Windows' CMD-compatibility LIMITATION ** (may be lifted in
  a "ROS-specific" running mode of CMD): only allow standard commands to
  be specified as parameter of the CALL command.

  This reparsing behaviour can be observed in Windows' CMD, by dumping
  the interpreted commands after enabling the cmd!fDumpParse flag from
  a debugger (using public symbols).

- When reparsing, we should tell the parser to NOT ignore lines that
  start with a colon, because in this situation these are to be
  considered as valid "commands" (for parsing "CALL :label").

  * For Windows' CMD-compatibility, the remaining escape carets need to
    be doubled again so that, after the new parser step, they are escaped
    back to their original form. But then we also need to do it the "buggy"
    way à la Windows, where carets in quotes are doubled either! However
    when being re-parsed, since they are in quotes they remain doubled!!
    (see "Phase 6" in https://stackoverflow.com/a/4095133/13530036 ).

  * A MSCMD_CALL_QUIRKS define allows to disable this buggy behaviour,
    and instead tell the parser to not not interpret the escape carets.

- When initializing a new batch context when the "CALL :label" syntax is
  used, ensure that we reuse the same batch file position pointer as its
  parent, so as to have correct call label ordering behaviour.

  That is,

  :label
  ECHO hi
  CALL :label
  :label
  ECHO bye

  should display:

  hi
  bye
  bye

  i.e., the CALL calls the second label instead of the first one (and
  thus entering into an infinite loop).

  Finally, the "CALL :label" syntax strips the first ':' away, so, as a
  side-effect, the command "CALL :EOF" fails (otherwise it would perform
  a "GOTO :EOF" and succeeds), while "CALL ::EOF" succeeds.

Fixes some cmd_winetests.

base/shell/cmd/parser.c

@@ -93,6 +93,9 @@ static BOOL bLineContinuations;
 static PTCHAR ParsePos;
 static PTCHAR OldParsePos;
 
+BOOL bIgnoreParserComments = TRUE;
+BOOL bHandleContinuations  = TRUE;
+
 static TCHAR CurrentToken[CMDLINE_LENGTH];
 static TOK_TYPE CurrentTokenType = TOK_END;
 #ifndef MSCMD_PARSER_BUGS
@@ -206,6 +209,9 @@ restart:
         if (!ReadLine(ParseLine, TRUE))
         {
             /* ^C pressed, or line was too long */
+            //
+            // FIXME: Distinguish with respect to BATCH end of file !!
+            //
             bParseError = TRUE;
         }
         else
@@ -445,7 +451,7 @@ ParseToken(
     IN TCHAR ExtraEnd OPTIONAL,
     IN PCTSTR Separators OPTIONAL)
 {
-    return ParseTokenEx(0, ExtraEnd, Separators, TRUE);
+    return ParseTokenEx(0, ExtraEnd, Separators, bHandleContinuations);
 }
 
 
@@ -1294,7 +1300,7 @@ ParseCommandBinaryOp(
     if (OpType == C_OP_LOWEST) // i.e. CP_MULTI
     {
         /* Ignore any parser-level comments */
-        if (*CurrentToken == _T(':'))
+        if (bIgnoreParserComments && (*CurrentToken == _T(':')))
         {
             /* Ignore the rest of the line, including line continuations */
             while (ParseToken(0, NULL) != TOK_END)
@@ -1445,7 +1451,7 @@ ParseCommandOp(
 
     /* Parse the prefix "quiet" operator '@' as a separate command.
      * Thus, @@foo@bar is parsed as: '@', '@', 'foo@bar'. */
-    ParseTokenEx(_T('@'), _T('('), STANDARD_SEPS, TRUE);
+    ParseTokenEx(_T('@'), _T('('), STANDARD_SEPS, bHandleContinuations);
 
     return ParseCommandBinaryOp(OpType);
 }