Is your feature request related to a problem? Please describe.

This issue is not a feature request, but rather a collection and proposal to rework some parts of the build-system and about answering the following general question:
Will rizin/cutter use meson-build consistently?

I started to create the changes to rizin, cutter and rz-ghidra project as I wanted to build all three projects in one go with meson-build without utilizing git-submodules or any Cmake-Meson-build-glue-scripts. I realized that the meson-build integration is not consistent.
This makes things quite difficult, as it would require to install librz and rz-ghidra in order to debug or check them.
However, meson offers good features to prevent such as situation (such as wrap-mode force fallback, etc.).
I therefore created a code-state where it is absolutely possible to develop all three projects within one build folder with just one silly work-around to make the sleigh-language-defs available to cutter (install it temporarily in the build-dir, c.f. below).

Describe the solution you'd like

The idea is really easy written, but rather complicated and cumbersome to achieve. It was necessary to do the following things:

• Make it possible to add rizin as a subproject to cutter, by (closes: Make a Meson Wrap for Rizin library rizin#3454)
  • Making it possible to configure rizin, even if rizin_exe target is not required, nor build
  • Adding or updating all necessary wrap-files to rizin for potential
  • Several smaller fixes for includes and deps in rizin
  • Replace add_global_arguments against add_project_arguments (addressed previously in: meson: do not use add_global_arguments() rizin#3706)
  • Making it possible to use the meson_git_wrapper.py from a subproject
  • Replace the project-version with a meson-compatible version (i.e. without the v-prefix)
  • Get rid of the check_meson_subproject_py-commands! These are redundant with mesons
    force_fallback- and wrap_mode-options and introduce incompatbilities.
  • Get rid of the static_runtime-option! This is redundant with mesons built in
    prefer_static-option
• Make it possible to add rz-ghidra as a subproject to cutter, by
  • Creating a subproject, including a wrap-file and packagefiles for ghidra
  • Adding meson-build scripts for rz-ghidra
  • Adding other wrap-files to rz-ghidra (such as rizin)
• Add everything to cutter
  • Add wrap-files for rizin and rz-ghidra
  • Add meson-build scripts

The linked branches could then be tested, by configuring a build-directory (in the cutter-branch) with:
meson setup -Dwrap_mode=forcefallback -Dprefix=$(pwd)/build/install build
and compile it with:
ninja -C build install

Describe alternatives you've considered

I'm not sure if this is in anyway desired or appreciated...

My meson-proposal lacks several features that are currently available in CMake (such as RZ_LIBSWIFT, RZ_LIBYARA, etc.)

I know this still has a far way to go. However, I think there are great opportunities! E.g. using sanitizer, toolchains, configurations, compiler-features or dependencies consistently over all parts of the project during development or even packaging. I really appreciated meson-build in the past and I hope there is appreciation for it here in the cutter/rizin community as well.

Additional context

Please note the list of branches that have been created to support this effort:
(NOTE: Branches are listed in the necessary order to merge them!)

1. https://github.com/amibranch/rizin/tree/rizin_as_subproject
2. https://github.com/amibranch/rz-ghidra/tree/add_meson_build
3. https://github.com/amibranch/cutter/tree/add_meson_build

Pull-Requests from these branches will be created, only if feedback to this issue is available.
Please note: The branches do not yet apply most of the developer-guidelines to the underlying projects (specifically regarding testing and documentation)