Switch to GLPI core tools

[froozeify]

This PR is aimed to use the native core tools that will be release soon (glpi-project/glpi#22465)

For now I have created an image based on the branch so we can test.

This should tested once glpi-project/glpi#22465 is officially merged

I have tested with mreporting plugin (fork)

https://github.com/froozeify/GLPI_plugin_mreporting/releases

10.x CI : https://github.com/froozeify/GLPI_plugin_mreporting/actions/runs/21394446711
11.x CI : https://github.com/froozeify/GLPI_plugin_mreporting/actions/runs/21394458696

[froozeify]

Question for @Rom1-B @stonebuzz The core plugin:release command now extract the plugin version from the setup.php file is it ok for you ?
Or it should rather have a param to be overloaded ?

The ci inputs.tag is now only used to checkout the declared tag so it should be ok but I just want to be sure.

[stonebuzz]

The release process is handled by the release-workflow repository:
https://github.com/glpi-project/plugin-release-workflows

In particular, the workflow
auto-tag-new-version.yml
https://github.com/glpi-project/plugin-release-workflows/blob/v1/.github/workflows/auto-tag-new-version.yml

automatically extracts the version number from the PHP constant defined in the setup.php file.
This logic can be seen here:
https://github.com/glpi-project/plugin-release-workflows/blob/0b8b4337d15a0556cc888c00e4ff6125b0cccbde/.github/workflows/auto-tag-new-version.yml#L24C11-L24C12

The extracted version is then used to create a new Git tag.

Once the tag is created, the actual release is performed by the following workflow:
publish-release.yml
https://github.com/glpi-project/plugin-release-workflows/blob/v1/.github/workflows/publish-release.yml

This workflow is responsible for executing the effective release process triggered by the newly added tag.

So yes, this should be fine for the release.