Non-standard command line parsing misinterprets semicolons inside arguments

### Windows Terminal version

1.13.11431.0

### Windows build number

10.0.19044.1706

### Other Software

MSYS2 / Git for Windows bash (but really anything that regularly uses semicolons in their arguments, including filepaths)

### Steps to reproduce

Relates to

https://github.com/microsoft/terminal/pull/11314#issuecomment-926399451
https://github.com/microsoft/terminal/pull/11314#issuecomment-926742571
I hope that given @lhecker already expressed his doubts about the current behaviour, there would be some motivation for a fix-by-breaking-change here.

Use your favorite way to create a process on windows, I used
```cs
using System;

namespace CreateProcess
{
class Program
{
static void Main(string[] args)
{

while (true)
{
var line = System.Console.ReadLine();
try
{
var command = line.Substring(0, line.IndexOf(" "));
var args2 = line.Substring(line.IndexOf(" ") + 1);
System.Diagnostics.Process.Start(command, args2);
} catch (Exception e) { }
}
}
}
}
```

start the following command line
`wt.exe sh -c 'echo abcd\n && read -p prompt'`
wt:
sh:

all works fine:

now change && for ; -> start:
`wt sh -c 'echo abcd\n ; read -p prompt'`

wt:
sh:
will fail

Now, I am able to take that somebody decided that semicolon `;` as an **argument** is a good tab splitting character, however obviously this is problematic in context of standard *nix shells.

However, it is worse. WT ignores the "good citizens" rules about how command line is supposed to be parsed on windows (I really enjoyed reading this one again after long time).
https://daviddeley.com/autohotkey/parameters/parameters.htm

WT interprets semicolon `;` anywhere, in any argument, as command to spawn new tab, even if it is in a middle of "what should be parsed as a single argument" on windows!

repro steps:
command line: `wt.exe sh -c "'echo abcd\n ; read -p prompt'"`

wt:

the argument gets torn apart by the semicolon and the argument fails to start

there should be just one tab, and the command line to start `sh` should like `sh -c "'echo abcd\n ; read -p prompt'"` (does not matter if `sh` can handle that well or not, see note bellow too)

also:
command line: `wt.exe sh -c 'echo abcd\n; read -p prompt'` should work too, because the `;` is not an isolated argument, but part of the argument `abcd\n;` So the command line passed used to start sh should be simply `sh -c 'echo abcd\n; read -p prompt'`.

note: `sh` is parsing the command line in a shell-way, that's why the argument with inner command line, passed after the `-c` argument, can be enclosed in single quotes `'`; However that is just a feature of this particular reproduction steps and does not affect the "core issue" in WT.

### Expected Behavior

WT **does not** treat `;` that are part of an command line argument (https://daviddeley.com/autohotkey/parameters/parameters.htm#WINCRULESCHANGE ,referencing MSDN docs) that contains other characters then the single `;` (assuming spaces/tabs around arguments are trimmed by the command line argument parsing code) as `create new tab` commands.

### Actual Behavior

WT treats all `;` in all arguments as `create new tab` commands. As a consequence it is miss-interpreting arguments designed to reach "target CLI application".
Such behaviour does not have any grounds in standard windows command line parsing procedures and leads to confusion and need for special workarounds, that would need to dynamically rewrite arguments being passed to WT.

No source file or test is named. Start by reproducing the two wt.exe commands with the supplied Windows Terminal and MSYS2/Git Bash details, then trace the command-line parsing entry point that splits semicolon-separated tabs. Done means semicolons inside a single argument are passed through unchanged, while standalone separators still create new tabs.

Written by the indexing model from the issue text.