[Request] Add support for plugins to define coloring strategy in GCODE viewer

[foosel]

See PR #1503 which sadly clashes with the color coding done to distinguish multiple extruders.

It would be interesting to allow the user to switch between multiple color strategies within the GCODE viewer, instead of forcing multi extruder color coding.

Examples of interesting coloring options:

• multi extruder
• speeds
• temperatures
• potentially even extrusion type (perimeter vs infill vs support) if somehow extractable from the GCODE file
• progress through layer as in #1503

Those coloring options should be providable by (frontend) plugins.

The involved steps would (roughly) be the following:

• define a generic interface on the GCODE viewer to allow external calculation of the color to use for a gcode line segment, similar to current printer profile injection - the goal is to keep the very low coupling between OctoPrint and the GCODE viewer that is currently in place, with the viewer's view model acting as the only glue code between the two
• migrate current multi extruder color strategy to utilize that interface
• define a plugin interface feeding into this color strategy interface from OctoPrint view models(?)
• integrate a switch into the existing GCODE viewer UI to allow selecting the coloring strategy to be used

Also potentially related: #838

[bjcosta]

I would find the ability to assign colour to temperature useful to verify a temperature tower is in fact doing what I wanted. Not a major feature, but useful for this use case. The above described feature would be a good way to achieve that