refactor(selection-panel): improved open/close flow and animation

[TomMenga]

This PR aims to solve the problems relative to the open/close events emitted by the selection-panel.
We have received no complaints, so I expect nobody is using them so far.
Might solve #2309

Changes

• Converted the open/close animation from css-transition to css-animation. CSS animation provides a more consistent behavior and always emits animationend events.
• Refactored the code so that we have a single method that takes care of checking the state and to open/close the panel

To discuss

• Should a panel that uses force-open emit events?
• Should a panel that uses force-open animate?

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

❗ No coverage uploaded for pull request base (main@ca278d5). Click here to learn what that means.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2360   +/-   ##
=======================================
  Coverage        ?   93.55%           
=======================================
  Files           ?      221           
  Lines           ?    23419           
  Branches        ?     2100           
=======================================
  Hits            ?    21909           
  Misses          ?     1474           
  Partials        ?       36           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jeripeierSBB]

Now there is an initial animation which should not be there (compare to current version).

Should a panel that uses force-open emit events?
-> In my opinion yes, you don't have to listen to it if you don't care ;)
Should a panel that uses force-open animate?
-> no

[TomMenga]

Now there is an initial animation which should not be there (compare to current version).

Should a panel that uses force-open emit events? -> In my opinion yes, you don't have to listen to it if you don't care ;) Should a panel that uses force-open animate? -> no

I will clarify the current and past situation.

Before the update:

• No animation on init (by looking at the code, it seemed not intentional but just a happy outcome)
• force-open did animate (except if it was initialized with it)
• events were always emitted (there were some broken cases where it would only emit the willOpen)

I suggest that we keep the same behavior, so:

• No animation on init
• force-open does animate (except if inited with it)
• events always emitted

@jeripeierSBB what do you think?

[dauriamarco]

LGTM. I'm just not really sure if we should animate the panel if we add the force-open, but I think it's just a small detail to be confirmed.

[jeripeierSBB]

Now there is an initial animation which should not be there (compare to current version).
Should a panel that uses force-open emit events? -> In my opinion yes, you don't have to listen to it if you don't care ;) Should a panel that uses force-open animate? -> no

I will clarify the current and past situation.

Before the update:

• No animation on init (by looking at the code, it seemed not intentional but just a happy outcome)
• force-open did animate (except if it was initialized with it)
• events were always emitted (there were some broken cases where it would only emit the willOpen)

I suggest that we keep the same behavior, so:

• No animation on init
• force-open does animate (except if inited with it)
• events always emitted

@jeripeierSBB what do you think?

@TomMenga sounds good to me

[jeripeierSBB]

LGTM. thanks!