ci: ensure portable jextract code, to match deploy release build

[Marcono1234]

Relates to #171 and #172

Changes the ci.yml workflow so that it is more similar to the deploy.yml workflow, by running jextract on Linux and then using that code on the other platforms (Windows and macOS).

The changes have this effect:

• All previously existing job matrix runs now use the jextract code generated for Linux on JDK 25
  (to match what deploy.yml is doing; this also surfaces the failures of Version 0.26.0 does not work on Windows due to incompatible jextract code #171)
• 2 new matrix jobs where added, one for Windows and one for macOS, which run jextract themselves
  (this is mainly to ensure that local builds on these platforms work, in case users build the project themselves instead of using the release versions)

What do you think?

[Marcono1234]

Side note: GitHub currently implicitly includes the matrix arguments in the job name, e.g. "Test package (windows-latest, 25, true)". Is that ok or would you prefer if name was more descriptive?

[Marcono1234]

@ObserverOfTime, do you think this PR here is useful? The code duplication is not ideal though; maybe it could be reduced by using for example a reusable workflow, but I am not sure.

[ObserverOfTime]

I'll look into it if #172 wasn't enough.

[Marcono1234]

To me it looks like the fix in #172 was enough (thanks for that!). Both for my local Windows build and CI it works with jtreesitter 0.26.1.

This PR here was meant rather as a way to detect similar issues in the future in advance.

An alternative might be to perform this check somehow as part of deploy.yml, e.g. first run only mvn package, then use the JAR to test on Linux, macOS and Windows and afterwards publish. But I am not sure if there is an easy way to use that JAR instead of the project sources for the test then, maybe with a Maven profile which sets the JAR as system dependency and disables the compiler goal (?).