Enhance highlighters possibilities

[johnd0e]

New highlight-portal-history plugin (#436) shows interesting features, that might be useful for other plugins:

1. "Negative" highlighting: sometimes we may be interested in portals that lacks some features.
   Currently this is implemented with separate highlighters, but that is not very convenient, as it adds more clutter to the list.
   May be better to have special control to reverse effect of any current highlighter.

2. Sometimes highlighting is not "catchy" enough, and we might want to make those portals better visible by dimming all others.
   For highlight-portal-history (after portal-history: separate styles #441) it is easily achievable, as we introduce special (optional) styles there: other*: is set, they make other portals smaller in radius, or not color-filled, or whatever you define in that style.
   And again, such approach could be useful for all others highlighters, and better if that would not be hardcoded, but possible to toggle on-the-fly (also requires some control shared by all highlighters).

3. Currently we call "highlighter" those plugins that change style of leaflet CircleMarker, and we are limited with its features.
   May we should allow more transformations, like adding ornaments (similar to Portal History Ornaments #445), which make things more complex (highlighter should provide separate function to undo changes).

4. It'd be useful to have several highlighters active simultaneously.
   It'd make sense especially if we could control their priority, and have ability to customize styles.

We can discuss here:
a. How that should look from user point of you. How to control new features.
b. How that should be implemented in API, and plugins. Perhaps not every plugin needs mentioned features, so they somehow to define their possiilies.

Related: #105

[MysticJay]

@johnd0e 3) we could change the marker from a graphical object (circle) to a dynamically assigned "pin object".
this object can be different for each portal, but i fear a performance problem with that.

[le-jeu]

a. An UI such as bookmark could match the needs, with

• customizable order
• enable/disable/reverse on each line (or two list, enable/disable, and a checkbox for reverting if the highlighter has this feature)

but, this needs an idea for highlighter menu on android, and a suitable place for desktop (since a select list wont work)

b. I don' think there is a need to allow customization from any plugin into any highlighter with a complex API, (4.) should address most of the needs (#251 and #437)

1. some (most?) highlighters apply several rules depending on the portal data, reverting isn't well defined, but it can make sense as variation of an highlighter (like captured/visited => not visited/not captured) (to be opposed to capture => not captured)
2. this can be solved applying a list of highlighters instead of only one (4.), letting to an highlighter the job to fix visibility issue wrt the user taste, relying on the current applied style of the portal.
3. ...
4. see 2.