[CI] Add basic tests action workflow with one job

[jbampton]

Apache Airflow uses this same basic check:

https://github.com/apache/airflow/blob/a9a9c5a57fbaaa11499967b39bac11adedea857e/.github/workflows/basic-tests.yml#L270

We don't have much test coverage running on Windows.

Should be quick to run on the GitHub CI

Did you read the Contributor Guide?

• Yes, I have read the Contributor Rules and Contributor Development Guide

Is this PR related to a ticket?

• No:
  • this is a CI update. The PR name follows the format [CI] my subject

What changes were proposed in this PR?

Minor improvement one more check.

Maybe we can add more basic test jobs in future ?

How was this patch tested?

Did this PR include necessary documentation updates?

• No, this PR does not affect any public API so no need to change the documentation.

[jiayuasu]

Why do we need to test git clone on Windows?

[jbampton]

From Google:

Testing git clone on Windows is essential because of how the operating system handles files differently than Linux or macOS. Since Git was originally designed for Linux, several "Windows-specific" behaviors can cause a clone to fail or corrupt the project if not properly configured.
The primary reasons for testing on Windows include:

1. Line Ending Inconsistencies

• The Issue: Windows uses Carriage Return + Line Feed (CRLF) for new lines, while Linux and macOS use just Line Feed (LF).
• The Risk: Without testing, a clone might automatically convert all files to CRLF, which can break scripts (like .sh files) intended to run in Docker or cross-platform environments.
• The Fix: Developers often use the git config --global core.autocrlf true setting to manage these conversions automatically.

2. Case Sensitivity Conflicts

• The Issue: The Windows file system is typically case-insensitive (e.g., README.md and readme.md are the same file), whereas Linux is case-sensitive.
• The Risk: If a repository contains two files with the same name but different casing, cloning on Windows will result in a path collision. One file will overwrite the other, or the clone will fail with an error.
• The Fix: Testing ensures that the repository structure is compatible with the core.ignorecase setting commonly used on Windows.

3. File Path Length Limits

• The Issue: By default, Windows has a "MAX_PATH" limit of 260 characters.
• The Risk: Deeply nested projects (common in Node.js or Java) may fail to clone because the resulting file paths are too long for Windows to handle.
• The Fix: Testing identifies if you need to enable git config --system core.longpaths true to bypass these limits. [6]

4. Permission & Tooling Differences

• Permissions: Windows does not use the same POSIX file permissions as Linux. This can lead to "executable" bits being lost or ignored after a clone.
• SSH vs. HTTPS: Windows often requires specific credential managers or configurations for SSH keys that differ from Unix-based systems.
• Network Performance: Features like "Receive Window Auto-Tuning" in Windows can sometimes cause git clone to be significantly slower or more prone to timing out than on other platforms.