examples: Treat SDL2 headers as system headers

This makes those headers included with -isystem rather than -I,
which makes the compiler skip producing any warnings about them
(as they're expected to be out of the user code's control).

This avoids warnings with newer versions of the
dav1d-debian-unstable CI image, warnings (treated as errors in CI)
like this:

    In file included from /usr/include/SDL2/SDL_config.h:51,
                     from /usr/include/SDL2/SDL_stdinc.h:33,
                     from /usr/include/SDL2/SDL_main.h:25,
                     from /usr/include/SDL2/SDL.h:31,
                     from ../examples/dav1dplay.c:33:
    /usr/include/SDL2/SDL_config_unix.h:186:9: error: 'HAVE_GETAUXVAL' redefined [-Werror]
      186 | #define HAVE_GETAUXVAL 1
          |         ^~~~~~~~~~~~~~
    In file included from ../examples/dav1dplay.c:27:
    ./config.h:66:9: note: this is the location of the previous definition
       66 | #define HAVE_GETAUXVAL 0
          |         ^~~~~~~~~~~~~~

Recently, Debian Unstable has switched from providing the
actual SDL 2 to providing the SDL 2 API through the sdl2-compat
package on top of SDL 3.

The SDL 2 headers expose their full config.h as part of their
installed headers (that the user code ends up including). This
includes unnamespaced defines, such as "#define HAVE_GETAUXVAL 1".

This issue hasn't shown up with the original SDL 2 package in
Debian, due to a Debian packaging detail. While most SDL 2
headers are installed in /usr/include/SDL2 (and user code
includes it as <SDL.h>, requiring the build system to include
/usr/include/SDL2), the Debian packaging has replaced
/usr/include/SDL2/SDL_config.h with a header that includes
<SDL2/_real_SDL_config.h>, which then gets resolved in
/usr/include/x86_64-linux-gnu/SDL2. Due to this being included
from a compiler default system include path
(/usr/include/x86_64-linux-gnu), no warnings about the header
was printed, even though that one also produced the same kind
of conflicting redefinitions. (We could also avoid the same issue
by attempting to include <SDL2/SDL.h> instead of <SDL.h>,
avoiding the use of the build system provided include directory,
resolving that from /usr/include, and having the compiler consider
it a system header.)

The sdl2-compat package in Debian doesn't redirect that header
in the same way, but includes SDL_config_unix.h in the same
directory in /usr/include/SDL2. Due to this being included
from a user specified -I (as long as it is included as <SDL.h>,
not <SDL2/SDL.h>), it's considered a user header, and warnings
are printed for it.

It seems like SDL 3 no longer exposes their config.h headers as
part of the installed headers.

The conflict between SDL 2's config.h's HAVE_GETAUXVAL and
our stems from the fact that we only try to detect GETAUXVAL
on architectures where we want to use it (arm/aarch64, loongarch,
ppc or riscv). On x86, where we don't need it, we don't try
to detect it, and set "#define HAVE_GETAUXVAL 0" in our
config.h.

To avoid warnings due to the conflict, we can declare the
SDL 2 dependency with the argument "include_type: 'system'",
which should silence any warnings in the SDL headers. This
Meson feature is available since Meson 0.52.0 (and we currently
require Meson 0.54.0).

An alternative way to avoid the redefinition conflict would be
to always try to detect getauxval on all architectures, to make
our config.h agree with SDL 2's config headers.

A third (and much more hacky way) around the conflict would be
to avoid the public SDL headers including the SDL_config header
by defining "SDL_config_h_" before including SDL.h. Doing this
also requires manually including a couple more standard headers
before SDL.h (stdint.h, stdio.h, stddef.h).

examples/meson.build

@@ -40,7 +40,7 @@ dav1dplay_sources = files(
     'dp_renderer_sdl.c',
 )
 
-sdl2_dependency = dependency('sdl2', version: '>= 2.0.1', required: true)
+sdl2_dependency = dependency('sdl2', version: '>= 2.0.1', required: true, include_type: 'system')
 
 if sdl2_dependency.found()
     dav1dplay_deps = [sdl2_dependency, libm_dependency]