Add compatibility layer in SDK 3.1 to support plugins developed for SDK 3.0

[Arthurk12]

Description:
Currently, we maintain two separate branches of the plugin SDK: one compatible with BigBlueButton v3.0.x(SDK v0.0.x) and another compatible with BigBlueButton v3.1.x(SDK v0.1.x). These branches differ only minimally, mainly in terms of visual components (extensible areas) that were introduced or removed as part of the UI redesign in v3.1.x.

Due to this separation, many plugins have also been developed with two branches — one targeting SDK v0.0.x and another targeting SDK v0.1.x. However, in most cases, the plugin code is virtually identical across branches, and only minor UI differences exist. Maintaining multiple branches for each plugin adds unnecessary complexity and effort.

Proposal:
To simplify plugin maintenance, I propose implementing a compatibility layer in SDK v0.1.x that would internally map or adapt the API/UI differences from SDK 3.0. This would allow plugins written for SDK v0.0.x to run seamlessly with SDK v0.1.x, eliminating the need for duplicate plugin branches.

Differences Between SDKs:

Present in SDK 3.0 but removed in SDK 3.1:

• ActionButtonDropdownOption
• ActionButtonDropdownSeparator

Introduced in SDK 3.1 (not available in SDK 3.0):

• AppsGalleryEntry
• MediaAreaOption
• MediaAreaSeparator

These differences are primarily UI-related and should be straightforward to handle via an internal translation or shim layer. For instance, ActionButtonDropdownOption and ActionButtonDropdownSeparator could be internally translated to the corresponding MediaAreaOption and MediaAreaSeparator components when running in SDK v0.1.x.