Add python 3.8/3.9 support for Windows GPU and Linux ARM64

[snnn]

Description:

1. Add python 3.8/3.9 support for Windows GPU and Linux ARM64

2. Delete jemalloc from cgmanifest.json.

3. Add onnx node test to Nuphar pipeline.

4. Change $ANDROID_HOME/ndk-bundle to $ANDROID_NDK_HOME. The later one is more accurate.

5. Delete Java GPU packaging pipeline

6. Remove test data download step in Nuget Mac OS pipeline. Because these machines are out of control and out of our network, it's hard to make it reliable and the data secure.

7. Fix a doc problem in c-api-artifacts-package-and-publish-steps-windows.yml. It shouldn't copy C_API.md, because the file has been moved into a different branch.

8. Delete the CI build docker file for Ubuntu cuda 9.x and Ubuntu x86 32 bits

9. And, due to some internal restrictions, I need to rename some of the agent pools

Org	Old name	New Name
onnxruntime	Linux-CPU	Linux-CPU-2019
aiinfra	Win-CPU-2019	Win-CPU-2021

Motivation and Context

• Why is this change required? What problem does it solve?
  To have full support for python 3.8/3.9.

Note: there is a tiny issue for the GPU java packaging part. The package name is wrong. I'll address it separately.

• If it fixes an open issue, please link to the issue here.

[snnn]

/azp run Windows CPU CI Pipeline

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[edgchen1]

looks like there is a way to convert to lower case: https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html#Shell-Parameter-Expansion (search for ${parameter,,pattern})
how about ${IsMacOs,,} == "true"?

[edgchen1]

why not keep this parameter and pass the correct value? seems better to not depend on azure devops variable names like BUILD_SOURCESDIRECTORY outside of build definitions.

[edgchen1]

could add an additional parameter for the binaries directory

[snnn]

Yes, then I need to add another parameter, which requires modify more files(all the callers of this script). That's why I choose this.

[snnn]

Indeed I would prefer to pass less parameters when possible. The more we have, the more likely we could make some errors during the passing, for example, missing one parameter or the order is wrong.

[edgchen1]

that's what error handling is for :)
or named command line options
can handle it later

[snnn]

Oh, I forgot to mention, sometimes the file is called from docker, sometimes it runs directly in the host environment. If we use the azure devops variable names directly, then in the first case we need to pass it, in the second case we don't and we can directly use the vars.