Contextual links are broken

There are 2 approaches we can take to address this:
1. Add support for `contextual` module as an exception to passthrough it's styles.
OR
2. Implement our own support for the contextual links if #1 is not possible.

I suggest doing a small POC for #1.

The `Version` field purpose from https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-...

Normally, set this to the current development version of the project, rather than the exact release version where you noticed the problem. For Drupal Core, see also the page on backport policy.

This is puzzling me, because this means that all of the issues would need to have their version field changed every time we release. But I will comply.

I've debugged this and the problem is that the list of links does not receive the 'contextual-links' class. If this class is added - everything works (you can try this by editing a <ul> element with Contextual links in the Web Inspector console and adding the 'contextual-links' class).

It does not receive the class because CivicTheme does in `civictheme_convert_attributes_to_modifier_class()` function:

// Remove class from attributes to avoid duplicated 'class' attribute on
// the element.
unset($variables['attributes']['class']);

As it can be seen in the comments, the intention here was to remove duplicated classes: for modules and themes classes are added via `$variable['classes']`, some through `$variables['attributes']['class']` etc; this function tried to unify this and convert to a UIKit's `modifier_class` property - this property is used in all component to set a CSS class. It was deliberately separated from unexpected use of attributes like `class`, `classes` and `attributes` - try searching the Drupal core and contrib for `{{ class` and you will see that some use `{{ class }}`, some `{{ classes }}` and some `{{ attributes}}`) The problem lies in the Drupal API that treats classes as special attributes, allowing developers to use both `{{ classes }}` and `{{ attributes }}` in their Twig templates.

So, this function cannot predict how core, module and theme developers are going to build their twig templates. This is why CivicTheme uses an opt-in mechanism - to guarantee that visual consistency until a module or theme are explicitly opting in to have their classes correctly specified in the template. The opting-in itself could be in a form of a custom template override which uses `modifier_class` variable directly within `class` attribute on the HTML element OR a preprocess that sets `$variables['modifier_class'] = FALSE`, which disables removal of `$variables['attributes']['class']` value.

I hope this clarifies why CivicTheme strips away classes. Now back to the problem.

The Contextual links are rendered using the `links.twig.html` which are relying on attributes:

<ul{{ attributes }}>

---

Possible solutions
1. `links.twig.html` - override within CivicTheme to use a custom component consisting of the UIKit's menu/navigation, which use `modifier_class`.
OR
2. Add preprocess for the contextual links and set `$variables['modifier_class'] = FALSE`. This will prevent the processing.
OR
3. Remove the `unset($variables['attributes']['class']);` and hope that duplicated classes will not break websites (they will as history has shown).