Add strict type declarations and modernize codebase

[sukhwinder33445]

Add strict type declarations to all method parameters, return types, and
properties throughout the codebase. Remove redundant runtime type checks
now enforced by the type system. Update PHPDoc to use nullable shorthand
and compact format. Replace list() with array destructuring, and
switch/case with match expressions. Remove the InAndNotInUtils
trait, which was introduced to suppress PHPStan errors before strict
typing was available. Clean up deprecated test helpers.

Raise the minimum required ipl/stdlib version to adopt its strict type
declarations.

requires Icinga/ipl-stdlib#63

[BastianLedererIcinga]

The InAndNotUtils trait is currently incompatible with ipl\Stdlib\Filter\Condition.

[BastianLedererIcinga]

The rest looks good.

The base branch was changed.

[BastianLedererIcinga]

Local unit tests all pass when using the other modernize branches.

[lippserd]

requires Icinga/ipl-i18n#26 (for tests to run, compatibility issue)

Why? ipl-i18n is not a dependency of either ipl-sql or ipl-stdlib.

---

77124d2 states "non-breaking", but it does introduce strict types on Cursor::limit() and Cursor::offset(), which requires a newer version of ipl-stdlib. Plus, the changes only become testable through follow-up commits, which spreads related changes across multiple places and makes it harder to reason about the impact.

To keep things manageable especially with all the releases coming soon, it helps if we follow a few rules:

When we say non-breaking, we mean it: no dependency or consumer must need to change. Any test adjustments belong in the same commit, and if a newer PHP version is needed, composer.json should reflect that in the same commit with a note in the description.

When a change in an IPL component does require updates in consumers,
those consumer updates should land in a single commit that also bumps the version constraint in composer.json.
Since we don't have releases yet, pointing to a branch is totally fine:
ipl-i18n#13 is a good example of how to do that.
We'll change those to proper version constraints once we actually release.

In the end, we're aiming for two distinct release steps:

• first a non-breaking IPL release that's safe for Icinga Web and its modules,
• then a follow-up breaking release that coordinates updates across everything affected.

Clean, self-contained commits are important.

One more thing worth clarifying: breaking changes that only affect IPL don't need to live in a separate PR as long as the commits are self-contained.
However, anything that breaks Icinga Web and/or its modules does need to go into a new PR.

@BastianLedererIcinga @Jan-Schuppik Please check your PRs to make sure they comply with these rules. I've already adjusted Icinga/ipl-stdlib#63.

[sukhwinder33445]

I have adjusted the commits accordingly. Each commit is now self-contained.

[lippserd]

Please squash 197e119 and e752d91 into b244e12 as all changes are in response to ipl-stdlib introducing strict typing. Change commit title to, e.g., "Adapt to ipl-stdlib strict typing" and mention all changes in the commit description.