Explicitly add languages and plugins

[RunDevelopment]

Motivation

Right now, Prism has a few problems with how languages and plugins are added/loaded. To list a few of those problems in no particular order:

• Reloading languages/plugins causes their hooks to be added multiple times. (Add a way to remove hooks #1993)
• It's not possible to determine what languages/plugins have already been loaded just by looking at the Prism.languages and Prism.plugins namespaces.
• It is very hard to determine the aliases of a language. (see Prism should resolve aliases for hooks #2000 for more details)

All of these problems come from the fact that Prism instances have no control over their languages/plugins.

This issue proposes a new API to add languages and plugins that can be used to solve all of the above-mentioned problems.

Description

Instead of adding languages/plugins directly to Prism.{languages,plugins}, new functions Prism.{languages,plugins}.add will be used. The add functions will take 3 pieces of information:

1. The id of the language/plugin.
2. A function created the language/plugin.
3. Optional meta information such as aliases.

The add functions will do 3 things:

1. Add meta information and the function creating the language/plugin to an internal (or public?) registry.
2. Run the creator function to actually add the language.
3. Add aliases (if any).

API

/**
 * @param id The id of the language/plugin.
 * @param meta Information about the language/plugin.
 * @param createFn A function that add the language/plugin to the given Prism instance.
 */
Prism.{languages,plugins}.add(
	id: string,
	meta: Meta,
	createFn: (Prism: Prism) => void
): void;

interface Meta {
	/**
	 * A list of aliases of the current language/plugin.
	 */
	alias?: string | string[];
}

Usage

Prism.languages.add('my-lang', { alias: 'my-language' }, Prism => {
  Prism.languages['my-lang'] = { ... };
});

Note that this usage pattern is very compatible with the current way languages/plugins are added.

Advantages

• Since we have a registry of all loaded components, it's trivial to determine which ones are loaded and what their aliases are.
• This makes reloading easier since we just have to run the creator function again. No need to re-read/re-request any files.
• Since we know the component id, we can automatically remove old hooks of that component.
• We don't have to rely on IIFEs to prevent namespace pollution anymore.

Disadvantages

• We have to change every single language and plugin file.
• This will break compatibility with current third-party languages and plugins. They will most likely still work but aliases and reloading will not.

[RunDevelopment]

Implemented in v2.