Add loaders to routes with a chainable addLoader

[pleek91]

Description

Third step of #805, stacked on #809.

Loaders are a route's data, declared the way views are declared but with no component attached and no hold on rendering:

createRoute({ name: 'user', path: '/user/[id]' })
  .addView(UserView, { props: (route) => ({ id: route.params.id }) })
  .addLoader(async (route) => api.getUser(route.params.id))
  .addLoader(async (route) => api.getPosts(route.params.id), { name: 'posts' })

They are stored per match, alongside views, so a route's data can be derived from its matches the same way its views already are — including an ancestor's loaders, which a child should be able to use as its own.

Both chainable methods now rebuild through withRouteMethods. Previously addView re-attached only itself, so chaining a view after a loader would have dropped addLoader from the route — the two have to be re-attached together, and neither file needs to know about the other for that.

A loader name an ancestor already uses throws LoaderNameConflict. A route's data combines the loaders of every match, so the same name in two places would be ambiguous rather than an override — unlike adding a loader the route itself already has, which replaces it, as views do.

Nothing runs a loader yet. What this proves is declaration: names, prefetch configs, immutability, chaining in both orders, and ancestor conflicts.