feat: introduce frontend extenders

[SychO9]

Changes proposed in this pull request:
Prior to this, frontend extenders never actually worked before, nor could any extension use them at all as they weren't exported in compat either. This PR does the following:

• Refactor extenders in core for them to actually work:
  • They are now in the common/extenders directory to avoid conflicts with the extend.ts module).
  • An IExtender interface has been introduced.
  • Th Routes and PostTypes extenders have been adapted to the new changes and the Model extender was removed for a separate PR.
• Make use of the Routes and PostTypes extenders in bundled extensions.
• The extenders can be accessed by exposing an extend module from the extension, which contains an array of extenders.

Reviewers should focus on:

• JS Tests are only failing because check-typings is running before new typings are built.
• The bundled extension changes were made here as an example, but I can extract them into another PR if wanted. The commits are separated though, so it should be easy to review.

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).
• Core developer confirmed locally this works as intended.
• Tests have been added, or are not appropriate here.

[luceos]

I don't feel prefixing interfaces with an I is the way to go. We are trying to mimic the ideology of Laravel mostly and Laravel explicitly moved away from ISomething and SomethingInterface to Contracts\Something. Is there a way to do this here as well? For instance naming the IExtender something like Contract\Extends or Contract\Extensible. This, in my experience with Laravel, seemed to be a more eloquent way of using interfaces honestly. What do you think?

[SychO9]

I don't feel prefixing interfaces with an I is the way to go.

We are already using that convention with other frontend interfaces, so it would be inconsistent tbh.

We are trying to mimic the ideology of Laravel mostly and Laravel explicitly moved away from ISomething and SomethingInterface to Contracts\Something.

That's on the backend side though, and we don't actually mimic Laravel, we explicitly follow the PSR-2 coding style which promotes FooInterface AbstractFoo ...etc

I've changed the class name to ExtenderInterface though

[askvortsov1]

Is the name "helper" consistent with the concrete implementations included in core's routing helpers? Can we somehow refer to that, even if the type doesn't adds any additional structure or safety, if only for documentation?

[SychO9]

It's referred to as routeHelpers in core, so I think helper makes sense.

framework/framework/core/js/src/forum/routes.ts

Lines 41 to 51 in a595665

	export function makeRouteHelpers(app: ForumApplication) {
	return {
	/**
	* Generate a URL to a discussion.
	*/
	discussion: (discussion: Discussion, near?: number) => {
	return app.route(near && near !== 1 ? 'discussion.near' : 'discussion', {
	id: discussion.slug(),
	near: near && near !== 1 ? near : undefined,
	});
	},

[askvortsov1]

I don't feel prefixing interfaces with an I is the way to go.

We are already using that convention with other frontend interfaces, so it would be inconsistent tbh.

I would prefer being consistent across the frontend. Different languages have different coding styles, I prefer to stick to convention in each as opposed to forcing an odd middle ground.

[askvortsov1]

Great step towards a more consistent, declarative API. Sorry for the review delay!