Add Win_x86-64_Build_Tests github actions

[lygstate]

Superset #4495

Move get_platform_cmd_prefix into util.py
get_platform_cmd_prefix implement multiple times in multiple function.
Also add function get_python_cmd_prefix, call to python script always
add python command so that on windows, the python script doesn't have
executable permission also can be called.

test262 currently only support for python2, so use python2 command directly

appveyor.yml no need anymore

JerryScript-DCO-1.0-Signed-off-by: Yonggang Luo luoyonggang@gmail.com

[akosthekiss]

@lygstate This ain't right. Again, there are 7 commits stacked on top of each other in this PR. Nobody is going to review such PRs. I cannot even recall how may times we have asked you to avoid this. But still, you keep using PR branches as development branches. This is flooding maintainers mailboxes (every time you push a PR, maintainers get an email), and what's worse, it is flooding the CI (every time you push a PR, it starts a new job on our CI as well, not only on your fork). And you push very often.

I'm asking you again, don't use PRs for development. If there are dependencies between contributions, open PRs only for those that can be reviewed and landed on their own. Open the new PRs only when the dependencies got merged. Even if the process seems slow to you. The more PRs you open with such stacked commits, the more work you put on maintainers to sort out what can be reviewed, and the process will become even slower.

[lygstate]

@lygstate This ain't right. Again, there are 7 commits stacked on top of each other in this PR. Nobody is going to review such PRs. I cannot even recall how may times we have asked you to avoid this. But still, you keep using PR branches as development branches. This is flooding maintainers mailboxes (every time you push a PR, maintainers get an email), and what's worse, it is flooding the CI (every time you push a PR, it starts a new job on our CI as well, not only on your fork). And you push very often.

I'm asking you again, don't use PRs for development. If there are dependencies between contributions, open PRs only for those that can be reviewed and landed on their own. Open the new PRs only when the dependencies got merged. Even if the process seems slow to you. The more PRs you open with such stacked commits, the more work you put on maintainers to sort out what can be reviewed, and the process will become even slower.

OK