chore: remove leftover CMake checks for std::string_view (#1676)

* ci: suppress Node 20 deprecation and missing python-version warnings

- Injects `FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true` in all workflows to
  opt-in to Node.js 24 and suppress the deprecation warnings from
  multiple GitHub Actions.
- Specifies `python-version: '3.x'` for `actions/setup-python@v5` in
  `meson.yml` to fix the missing input warning.

* Fix C++11 ABI breakage when compiled with C++17 (#1668)

When JSONCPP_HAS_STRING_VIEW was defined, the library dropped the
`const char*` and `const String&` overloads for `operator[]`, `get`,
`removeMember`, and `isMember`, breaking ABI compatibility for projects
consuming the library with C++11.

This change unconditionally declares and defines the legacy overloads
so they are always exported, restoring compatibility.

* ci: add ABI compatibility matrix workflow

This adds a new GitHub Actions workflow to verify ABI compatibility across C++ standard boundaries. It explicitly tests the scenario where JsonCpp is built with one standard (e.g., C++11) and consumed by an application built with a newer one (e.g., C++23), and vice versa.

To facilitate testing the specific `std::string_view` boundary that is conditionally compiled, a new `stringView` demo application has been added to the `example/` directory and is consumed directly by the CI matrix to ensure standard library symbols link correctly across standard versions, build types (shared/static), and operating systems.

* fix: inline std::string_view methods to prevent ABI breaks

This commit completely eliminates the ABI breakage that occurs across C++ standard boundaries when using `std::string_view`.

Previously, when the library was built with C++17+, CMake would leak `JSONCPP_HAS_STRING_VIEW=1` as a PUBLIC definition. A C++11 consumer would receive this definition, attempt to parse the header, and fail with compiler errors because `std::string_view` is not available in their environment.

Conversely, if the library was built in C++11 (without `string_view` symbols), a C++17 consumer would naturally define `JSONCPP_HAS_STRING_VIEW` based on `__cplusplus` inside `value.h`. The consumer would then call the declared `string_view` methods, resulting in linker errors because the methods weren't compiled into the library.

By moving all `std::string_view` overloads directly into `value.h` as `inline` methods that delegate to the fundamental `const char*, const char*` methods:
1. The consumer's compiler dictates whether the overloads are visible (via `__cplusplus >= 201703L`).
2. The consumer compiles the inline wrappers locally, removing any reliance on the library's exported symbols for `std::string_view`.
3. CMake no longer needs to pollute the consumer's environment with PUBLIC compile definitions.

* run clang format

* finish clang format

* chore: remove leftover CMake checks for std::string_view

Fixes #1669

This removes the final vestige of the JSONCPP_HAS_STRING_VIEW build system logic.

As of the previous commit (inlining std::string_view methods into value.h to fix ABI breaks), the library no longer relies on the build system (CMake or Meson) to check for and define JSONCPP_HAS_STRING_VIEW.

The header value.h automatically activates std::string_view overloads purely by checking the consumer`s __cplusplus >= 201703L. Since none of the actual std::string_view symbols are compiled into the .so / .a library anymore, Meson (and CMake) builds are identical regardless of whether string_view is supported by the compiler building the library.

* format spacing better