Introduce PolarOpenButton (more clever name ~~optional~~ required) as separate component and use across fitting plugins

Description

A new component shall be introduced that handles opening a single plugin, pretty much as the IconMenu does, that is, including tooltip provision and using its icon. That component's WIP name is "PolarOpenButton". However, we found "PolarMaybeOpenButtonOrContentDirectly" could be deemed more fit; since that name isn't quite the catch either, there's some intense thinking required on this part.

The component shall then be used in plugins that may potentially "open" something; i.e., single-button elements like GeoLocation do not need this.

This wrapper may then be used for various plugins like LayerChooser, Filter, Attributions, and others that "open" a thing. It can be used as an alternative to the IconMenu for clients where this behaviour is deemed fit/neccessary, and shall be active during renderType: 'independent'. While I really like stuffing everything to the IconMenu, such cases may occur for e.g. Attributions on a regular basis, or when any action has particular prevalence for a client's function.

Since renderType is touched, please mind this:

renderType has three possible values, iconMenu, independent, and, only for Attributions so far, footer. It may prove worthy to, for this issue, change those values to iconMenu, independent, and always-open, where iconMenu behaves as previously, independent makes use of the new-to-write PolarOpenButton, and always-open just renders the contents that the button would open without such a wrapper. With such a solution, the decision whether the PolarOpenButton renders should be delegated to the very same to prevent code duplication amongst plugins. footer as value in Attributions wasn't semantic anyway as this footer could be placed e.g. layoutTag: 'MIDDLE_MIDDLE'.

Affected areas

In the components folder, a new component is to be written.

The PlaceablePluginOptions type has to be partially refactored, where a new type also providing always-open as renderType option is required across fitting plugins.

Out of scope

The IconMenu shall not be touched in the process, despite looking oddly fitting, unless you see a great chance to shorten duplicate code.

Start in the components folder and inspect the PlaceablePluginOptions type plus the listed fitting plugins to map their current renderType handling. Done means the new component and renderType options support the specified plugins, including GFI pin selections, while IconMenu remains untouched unless duplication can be reduced.