Extend make.py with a 'unittest' command to run an addon's tests with the Gramps environment applied

[eduralph]

Summary

Extend make.py with a unittest command so an addon's test suite can be run
through a single entry point that sets up the same environment Gramps provides —
GTK/GDK version pinning and gi dependency bootstrap — instead of the developer
having to remember those details by hand.

Background

Discussion on upstream PR 950 ("Pin GTK and GDK to 3.0 for the repo-root test
suite"). The pinning was centralised in the repo-root tests/__init__.py, which
unittest discover -s tests imports before any test module. That works for a
full-suite run, but it does not apply when a maintainer or developer runs a
single addon's tests directly, e.g.:

python3 -m unittest Form.tests.test_form_validator

Today the workarounds are clumsy and easy to get wrong:

• prepend the bootstrap test so the pin runs first —
  python3 -m unittest tests.test_make_listing Form.tests.test_form_validator, or
• set the gi bootstrap on the path —
  PYTHONPATH=.github/scripts/gi_bootstrap python3 -m unittest Form.tests.test_form_validator.

Both leak Gramps-environment implementation details (GTK pinning, dependency
loading) into every developer's workflow. The maintainers' consensus on the
thread (dsblank, GaryGriffin) was to abstract this away behind make.py.

Proposal

Add a unittest command following make.py's existing
<gramps_version> <command> [addon] signature:

python3 make.py <gramps_version> unittest <Addon>   # run one addon's tests
python3 make.py <gramps_version> unittest all       # run every addon's tests

The command should, before invoking the tests:

• apply the same GTK/GDK pinning the repo-root tests/__init__.py applies, and
• put the gi bootstrap (.github/scripts/gi_bootstrap) on PYTHONPATH,

so the addon's tests run on the same GTK 3 / GDK 3 stack and dependency setup a
real Gramps session uses — without the addon author having to add pinning or
dependency-loading logic to their own Addon/tests/__init__.py.

This keeps the principle that the addon developer is shielded from
Gramps-environment details and focuses on logic, and it gives the maintainer a
single command to run an addon's tests during review.

Open questions (from the thread)

• The <gramps_version> argument is irrelevant for running tests. GaryGriffin
  noted it reads as weird (make.py gramps61 unittest Addon). Keeping it preserves
  consistency with every other make.py command and the build-for-6.0/test-for-6.1
  use case; dropping it would need special-casing the arg parsing. Decide whether to
  keep it for consistency or special-case unittest to omit it.
• Local source tree requirement. make.py resolves GRAMPSPATH
  (../../.. by default). Confirm whether the unittest path can run without a
  built Gramps tree, or document that one is required.

Acceptance

• python3 make.py <version> unittest <Addon> runs that addon's tests with the
  GTK/GDK pin and gi bootstrap applied, with no per-addon test setup required.
• python3 make.py <version> unittest all runs every addon's tests.
• A developer no longer needs to prepend tests.test_make_listing or set
  PYTHONPATH by hand.

Dependencies

The gi-bootstrap path (PYTHONPATH=.github/scripts/gi_bootstrap) referenced above
arrives with the CI work in upstream PR 820; this command should integrate with
that bootstrap once it lands.