Remove all platform detection logging to eliminate stderr output during Clava startup

[Copilot]

Problem

During Clava startup, platform detection messages were being output to stderr instead of stdout, causing issues when running Clava silently in scripts. This occurred because Java's java.util.logging framework outputs to stderr by default.

For example, when running on Linux, users would see messages like:

Oct 06, 2025 7:19:24 PM pt.up.fe.specs.util.logging.TagLogger log
INFO: Could not determine Linux version, running at your own risk

These messages appeared at INFO level and were sent to stderr along with timestamp lines, making it difficult to run Clava cleanly in automated scripts.

Solution

Completely removed all logging statements from SupportedPlatform.java:

1. Removed all ClavaLog calls (5 total) from platform detection code
2. Removed MacOS version check and warning
3. Removed Linux version detection warning messages
4. Removed unused getMacOSVersion() helper method
5. Removed unused SUPPORTED_MAC_VERSION constant

Impact

• Silent execution: Clava now runs without any stderr output during platform detection
• No kernel version warnings: All Linux and MacOS version warnings have been completely removed
• Better script integration: Users can now integrate Clava into scripts without any unwanted stderr output
• No functional changes: The actual platform detection logic remains unchanged - still validates Linux version >= 5 and throws errors for unsupported platforms

Platform Detection Behavior

The platform detection logic still:

• Accepts Linux version >= 5 silently (normal case for modern kernels)
• Throws an error for Linux version < 5
• Throws an error for ARM-based platforms
• Handles version parsing failures gracefully by defaulting to LINUX_5

The only change is that these checks now happen silently without any logging output.

Fixes #210

Original prompt

---

This section details on the original issue you should resolve

<issue_title>First two logged lines output to stderr instead of stdout</issue_title>
<issue_description>The first two logged lines when running Clava are output to stderr instead of stdout:

Oct 06, 2025 7:19:24 PM pt.up.fe.specs.util.logging.TagLogger log
INFO: Current major Linux version is 6, only up to version 5.0 has been tested, running at your own risk

This causes some annoyance when mixing Clava with other scripts where we want it to run silently. I don't see a reason to output this as an error, particularly at level INFO, and stdout should be used instead.

Furthermore, is the Linux kernel version warning at all warranted?</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes #210

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[lm-sousa]

These changes should be done starting from "staging" as I know there are modifications pending in the same files this PR touches.

[tiagolascasas]

@copilot Nothing of this makes sense. Messages at level INFO should never be sent to stderr. It also doesn't fix the warning about the kernel version, which I want to get rid of entirely. And finally, the first line with the timestamp shouldn't be written to stderr as well.

[Copilot]

@copilot Nothing of this makes sense. Messages at level INFO should never be sent to stderr. It also doesn't fix the warning about the kernel version, which I want to get rid of entirely. And finally,...

You're absolutely right. I've now completely removed all logging statements from the platform detection code (commit cdd57a6). This eliminates:

• All stderr output during platform detection (no INFO messages, no timestamps)
• All kernel version warnings
• The unused MacOS version check and helper method

The platform detection logic remains unchanged - it still validates versions but now runs silently.

[lm-sousa]

@tiagolascasas It will probably never find the code responsible because it is deep in the specs-java-libs repo. I've seen it before. It never even reaches the Clava layer. It stays within the lara-framework.
One of the problems of the way our repos are structured.