Custom Class: New class adder feature

[RunDevelopment]

This adds a function to let the user define custom classes for specific tokens. Example:

Prism.plugins.customClass.add(function ({content, type, language}) {
	if (content === ':' && type === 'punctuation' && language === 'javascript') {
		return 'colon';
	}
});

(You can also define multiple such functions.)

The whole thing is implemented via the wrap hook, so content is the innerHTML of the token. I choose this over before-tokenize because for users innerHTML is easier to understand than the Prism token stream.

Further considerations

This feature is kind of a superset of Highlight keywords.
So maybe we could combine the two edit: merge HK into CC deprecate HK?

---

@MattMcFarland I hope this helps.

[MattMcFarland]

Looks promising!

[mAAdhaTTah]

My apologies–could you remind me what sparked this PR?

[RunDevelopment]

The idea was some people want to selectively highlight certain tokens differently from what we do.

In the above example (which was pre #2073), the colon : should be highlighted like an operator in JS. With this PR, people can do it without changing the language definition.
Another example is how #1743 includes keyword groupings and special names for certain operators for more granular highlighting.

The main purpose is to give the designers of themes more freedom, so they aren't limited to the way we choose to tokenize. Of course, you can also achieve this by modifying the grammar but that's a lot harder.

[mAAdhaTTah]

The API change is def necessary cuz content is probs the least useful aspect to add additional classes. Alternatively, we could pass it in as an object with the three properties, which would eliminate the question of what order to make them.

[RunDevelopment]

Also, regarding the API:
I don't like that prefix and map set the current prefix or map but add adds another mapper. So either we change the name to indicate this difference or we change the behaviour.
Thoughts?

[mAAdhaTTah]

Yeah, it kinda feels like map is a subset of what add does. Can we change map to use add such that it always adds a new mapper?

[RunDevelopment]

No, because:

1. rn, add can't modify existing classes. It doesn't even see them.
2. there is no method to remove the functions passed to add, so we can't overwrite the mapper.

[mAAdhaTTah]

Ok... maybe it makes more sense for add to just take a single function then, and overwrite the previous one? Since we didn't see a need for making the first 2 take multiple functions, and we haven't gotten complaints about it, it makes sense to keep them aligned by just having the single add function.

[RunDevelopment]

Sounds good, but this won't make add a superset of map. Is that still ok?

[mAAdhaTTah]

Yeah, I don't think that's a necessary goal at this point. At least this makes the behavior consistent.

[RunDevelopment]

Sorry for the late responses. I've been a little busy lately.

The only things stopping v1.18 are #1998 and #2074. TBH, #2074 modifies Core and isn't as important as #1998, so I'm fine with leaving it out of this release if it'll mean that we can release faster.

I'll do the changelog in the meantime.