Introduce List component family

[alexpaxton]

Why?

Within the currently available components there is no generic "list" component family. The closest components are the DropownMenu and DropdownItems but they are very opinionated and not designed for contexts outside of dropdowns.

In the InfluxDB UI there are a handful of components that resemble a list but each are slightly different. Between those cases, dropdowns, and right click menus there is an opportunity to consolidate and standardize. Why not have one family of components that can serve all these contexts and more?

Changes

• Introduce List family of components

Notes

• Instead of creating a separate version of ListItem intended for use with <a> or <Link> there is a prop for that. Due to how the children of ListItem and itself relate having an extra DOM element in between throws off the styling.
• Compared to the dropdown family the List components are much more composable
• Favoring backgroundColor and gradient as the means of colorization instead of ComponentColor enum
• Unlike dropdowns, each component can be colored individually
  • The styles are not dependent on DOM structure anymore
• Once this PR is merged, List can begin to replace parts of other components such as RightClick, SelectDropdown, and MultiSelectDropdown

Screenshots

Checklist

Check all that apply

• Updated documentation to reflect changes
• Added entry to top of Changelog with link to PR (not issue)
• Tests pass
• Peer reviewed and approved
• Signed CLA (if not already signed)

[alexpaxton]

Todo:

• Ensure styles exist for disabled state of items
• Make onClick optional for static display of information

[alexpaxton]

Switched to using InfluxColors / Gradients as the coloration method for list items (instead of ComponentColor).

• Polish the selected state of indicators with gradients
• Rename some contexts and add comments in the code
• Revisit ListLinkItem approach

[mavarius]

Just a few notes; looks good though, this will be useful.

[mavarius]

this opacity is used in several places, would it be worth making it a variable?

[mavarius]

Is undefined necessary here? Seems redundant to define a default prop as "undefined".

[alexpaxton]

The context needs some initial value set. I could do null instead. I could be wrong but I think it will complain if I don't set a value

[mavarius]

Ya, defining null would be better than defining undefined.

[mavarius]

Good to go with just the undefined to null changes.

[mavarius]

we can switch these to null too.