Expose code-group changes (or other UI-related events)

[Dschungelabenteuer]

Is your feature request related to a problem? Please describe.

This whole feature request originates from a single problem.

When using code-groups:

• The active tab of a code-group is displayed based on an active class.
• This active class is based on a click listener in the useCodeGroups composable.

Some of us may need to apply some logic whenever a specific code-group tab is displayed or hidden.
For example, vitepress-twoslash has its own click listener on code-groups that recomputes all floating elements (i.e. type-related poppers such as code compeltions). Unfortunately, it's not 100% reliable because this listener may trigger before the VitePress one.

In vitepress-twoslash's case, floating positions are recomputed before the "active" class is added by VitePress leading to wrong computed positions (because next active tab, which contains the reference node for positioning, is still not displayed).

Describe the solution you'd like

I think it might be useful to have some client-side channel emitting some UI-related events e.g. "switching between code-group tabs" , so that we may apply our own logic when such events occur.

I didn't think much about an overall and versatile implementation because

1. You might just not find that relevant/want to dig that further
2. If you were to consider such a feature, you would have a way better insight the best approach
3. I only had that code-group case in mind, and I gather you wouldn't stick to one specific use-case

However, if specifically talking about my code-group issue, here are my two cents:
(please don't mind the event names, they're just here to illustrate my suggestions)

1/ Good

• VitePress useCodeGroups emits a generic code-group:change when toggling "active" class.
• Consumer client watches for that code-group:change and runs its own logic (though it doesn't know which code-group triggered that event).

2/ Better

- VitePress `useCodeGroups` emits a `code-group:change` when toggling "active" class, including the relevant code-group (either the element itself or its id). - Consumer client watches for that `code-group:change` and runs its own logic which may be more _fine-grained_ because we know which code-group triggered that event).

3/ Best

• VitePress useCodeGroups emits a code-group:change when toggling "active" class, including both current and next elements (either the nodes themselves or their ids).
• Consumer client watches for that code-group:change and runs its own logic which may be even more fine-grained because we know which code-group tab is being hidden, and which one is being displayed.

Describe alternatives you've considered

I originally tried to patch this on vitepress-twoslash's side by using a MutationObserver waiting for that "active" class, but it seems kind of hacky/overkill. Having a dedicated interface on VitePress' side that we could officially rely on seems like a way better and safer approach.

I don't have any other use-case in mind, though.

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the docs.
• Read the Contributing Guidelines.
• Check that there isn't already an issue that asks for the same feature to avoid creating a duplicate.