Apply the workaround for CET suggested by Microsoft on JCOBridge

[masesdevelopers]

Locally the tests works well however on GitHub they fails, after added extra dump features on #574 using procdump under windows runners we got a strange message:

Searching for the meaning of FAST_FAIL_SET_CONTEXT_DENIED, a recent article was found: https://ptupitsyn.github.io/Ignite-on-NET-9/
As stated the CET is enabled by default: https://learn.microsoft.com/en-us/dotnet/core/compatibility/interop/9.0/cet-support.
In local tests maybe the CET feature is not enabled (shall be checked better), however GitHub maybe enable it by default: try to add <CETCompat>false</CETCompat> when compiling tests for .NET 9.

Another source for the problem is dotnet/runtime#109682

Originally posted by @masesdevelopers in masesgroup/JNet#573 (comment)

[masesdevelopers]

Seems that, testing only the activation of JVM using JCOBridge stubbed code under .NET 9 using windows latest GitHub runner, the issue is raised in one condition:

1. the test fails if it is made using an executable app host like:

MyApplication.exe

2. the test does not fail if it is made using dotnet app host like:

dotnet MyApplication.dll

To summarize the CET is activated when the project builds an executable (.exe), but if the same code is executed from dotnet command it does not fails: so we can conclude that, as stated in https://learn.microsoft.com/en-us/dotnet/core/compatibility/interop/9.0/cet-support, dotnet is not compiled with the CETCOMPAT flag.

There are two possible workaround to be applied:

• the executable using JCOBridge shall have CETCompat to false: this is the one proposed
• use dotnet to run the application instead to use the generated executable (test number 2)

A newer version of JCOBridge will be issued trying to compile the library to be CET compatible: it is not possible to act at JVM level because, for JCOBridge, the JVM it is considered a COTS and JCOBridge can use any version (11+) from any vendor.