docs: add a dedicated tree-shaking page - #1143

Tree-shaking is one of the reasons maxGraph exists, but the documentation only mentioned it in passing, scattered over
the Graph and getting started pages. Nothing explained what the library provides and, above all, what an application
must do to benefit from it.

The new page covers what tree-shaking is, why ES modules and side effects matter, why the result depends on the
bundler, what maxGraph provides and how it improved over the releases, and how to register only the shapes, edge
styles, perimeters, edge markers, plugins, codecs, i18n and logger an application actually uses. It closes with a guide
for migrating an existing `Graph` based application, which trims what `Graph` loads instead of adding to an empty
graph, so that the application keeps running and can be measured at every step.

Link the page from the pages describing the features it references, and resync the examples list with the README.

The page states how many built-in shapes, edge styles, perimeters, edge markers and plugins `Graph` loads. Assert these
counts in the tests of the corresponding registration functions, with a comment pointing at the page, so adding a
built-in element cannot silently make it wrong.

Accuracy fixes, all of them cases where the wording claimed more than the code does:

- `Graph` loads the *default* plugins, not every built-in one: `RubberBandHandler` is built-in but not a default. The
  getting-started tip and the mxGraph migration guideline said "all built-ins".
- The Graph page warned that registering the defaults sets a floor on the bundle, without saying why that holds even
  when the caller passes its own `plugins` list. `getDefaultPlugins()` is only called when the argument is omitted, but
  `Graph` imports it either way, so the plugin code is bundled regardless. Spelling that out strengthens the case for
  `BaseGraph` instead of leaving a claim that looks refutable.
- "Each family follows the same pattern: a registry, a granular API and a `registerDefault*` escape hatch" was false for
  three families out of five: plugins use the `plugins` option, codecs use `registerAllCodecs`, i18n and the logger use
  `GlobalConfig`. A reader could go looking for functions that do not exist. Each mechanism is now named, and what the
  families genuinely share, a broad shortcut next to the narrow one, is stated separately.
- "Primarily a configuration change, not an API change" glossed over the constructor, which does change shape. The graph
  API is what stays identical.
- The opening sentence of "Going Further" presented selective loading of shapes and plugins as future work. It was
  quoted verbatim from issue #665, written before `BaseGraph` existed in 0.18.0, and it contradicted the entire page.
  It now says selective loading is available and that what remains is finer-grained modularity.

Wording, in both copies of the examples list: "stories demonstrate" for subject-verb agreement, and "efficient
tree-shaking" without the article, the term being uncountable here.

The introduction also links to the Global Configuration page, which is the catalogue of the registries and
configuration objects the rest of the page tells you to use sparingly.

In the test, `jest.restoreAllMocks()` moves to the shared `afterEach`. `addSpy.mockRestore()` ran only after the
assertion, so a throwing test left the spy installed, `restoreMocks` not being enabled in the Jest configuration. The
shared hook also covers any spy added to this file later.