TimelineJS CSS libraries are improperly weighted

Problem/Motivation

The TimelineJS CSS libraries are improperly weighted. This issue applies to both the 7.x-3.x and 8.x-3.x versions

When I first began working on the 3.x upgrade I started in Drupal 7 with the default Bartik theme. It was apparent that Bartik's styles were leaking into the timeline in a bad way. As I rewrote the code to load the TimelineJS libraries, I gave its CSS a heavier weight, 200, in order to try and solve some of the theming issues. It worked partially, although Bartik's selector for <h2> elements, .content h2, meant that the event text on the navigation bar was still blown up in size several times what it should have been.

I think that I believed I was doing everyone a favor by preventing poorly-written theme CSS from contaminating the timeline styles. What I didn't realize at the time is that I was preventing people from easily overriding the styles when they wanted to do so. It wasn't until last week when I tried to theme a timeline for the first time that I discovered I'd made life difficult for themers.

Proposed resolution

In D7 the CSS library weight needs to be changed to CSS_DEFAULT (0). In D8 the libraries should be added to the CSS component group, which will also give them a weight of 0.

Backward compatibility is also an issue. To avoid breaking existing site themes there should be a means to retain the old weight.

In D7, backward compatibility can be accomplished by creating a new variable, views_timelinejs_css_library_group. The hook_library() implementation will check the value of the variable, defaulting to CSS_DEFAULT. An update function will be added that sets the variable to the old value for existing sites.

The BC issue is more complicated for the D8 version because the libraries are defined in the libraries.yml file. hook_library_info_alter() must be implemented and the CSS group array key changed. Aside from that, a new configuration setting will be added similar to the D7 version.

At the moment, it is my intention that this variable/setting be undocumented (except in this issue) and not configurable through the admin interface. Site builders will be free to use Drush or the Variable module to update them when they've checked compatibility with their theme. Otherwise, I don't really want people to know that this configuration is possible. Moving forward, new implementations will have the correct weight and I intend to remove the variable/setting in the next major version if one is ever released.