The commit:
1. use static property to configure a builder option
2. introduce the concept of dependencies to access the plugin's shared
   in builder option
3. make a plugin context the same for Plugin, BuilderOption and
   BuilderAction to have the same API in each class.

Before this commit, to define an option, we had to define a javascript
object that would contain the information of the option within the
`builder_options` resource.

```js
class MyPlugin extends Plugin {
    resources: {
        builder_options: [
        {
            selector: "div.selector",
            template: "my.owlTemplate",
            cleanForSave() {}
            // ... other option props
        }
        ]
    }
}

// For a custom component
class MyPlugin extends Plugin {
    resources: {
        builder_options: [
        {
            selector: "div.selector",
            template: MyCustomComponent,
            cleanForSave() {}
            // ... other option props
        }
        ]
    }
}

class MyCustomComponent extends BaseOptionComponent {
    // ...
}
```

When building anything for the builder, there is 3 classes that are
important: `Plugin`, `BaseOptionComponent`, `BuilderAction`.

In practice, the option object defined in builder_options feels
strange. On the other hand, making the configuration of the option as
a static property of the component somehow feels simpler as everything
related to that option is defined in the same class.

```js
class MyPlugin extends Plugin {
  resources: {
    builder_options: [MyCustomComponent]
  }
}

class MyCustomComponent extends BaseOptionComponent {
  static template = "my.owlTemplate";
  static selector = "div.selector";
  static cleanForSave(context) {}
  // ...
}
```

To have the same mental context in the 3 important class, they all
share the same API (`dependencies`, `dispatchTo`, `getResource`, ...)
(see `Editor.getPluginContext`)

To access a plugin shared method, it's now the same for `Plugin`,
`BuliderAction` and `BaseOptionComponent`:

```js
class MyCustomComponent extends BaseOptionComponent {
    static selector = "mySelector";
    static dependency = "myPlugin";
    myMethod() {
        this.dependencies.myPlugin.pluginMethod();
    }
}
```

To access a resource, dispatch, ...:

```js
class MyCustomComponent extends BaseOptionComponent {
    static selector = "mySelector";
    myMethod() {
        const resource = this.getResource('myResource');
    }
}
```

Forward-Port-Of: odoo/enterprise#96515
Forward-Port-Of: odoo/enterprise#94102

Steps to reproduce:
-------------------------
1. Install `hr_payroll` module
2. Enable debug mode and click on Become Superuser
3. Go to All Payslips and open any payslip record
4. Click on the Export Payslip button

Observation:
-------------------------
A 404 (Page Not Found) error appears when clicking the Export Payslip button

Issue:
-------------------------
The button triggers the route `/debug/payslip/<id>`, which was removed in the following commit
https://github.com/odoo/enterprise/commit/57969bcaf876a13c36794adeb47e0da938e297ad#diff-0105b1a6a9e742e7eeaf7cc727745ebd3932177378d46332d4ca854f931b3359
The route was never reintroduced afterward, but the Export Payslip button remained in the view.
As a result, clicking it leads to a 404 error

Solution:
-------------------------
1. Temporarily bypass the `action_export_payslip` function.
2. Remove the Export Payslip button from the XML in the master forward port branch, as doing so does not impact any existing customizations relying on that button

opw-5115946

Forward-Port-Of: odoo/enterprise#97361
Forward-Port-Of: odoo/enterprise#96359

The test 'test_customer_event_description' was failing inconsistently
due to a discrepancy in how the event description is generated.

The test previously relied on the base calendar model's logic, which
automatically creates a description by selecting the first partner
associated with the event (excluding the organizer) based on default
record ordering. This selected partner may not always be the actual
person who booked the appointment.

However, when a user books through the front-end, the controller
uses specific logic to build the description, correctly identifying the
booker and bypassing the model's default behavior.

This difference caused the test to occasionally choose the wrong partner
for the description, resulting in unpredictable failures.

This commit aligns the test more closely with the actual booking behavior
seen by users. It now explicitly prepares the event description using the
designated booker's details and prevents the base model logic from
interfering.

This ensures the test is reliable and accurately validates the description
content. A potential future improvement would involve refactoring the
controller's description logic into the model layer for better testability,
as the current test mimics the controller logic, which could diverge over time.

Task-5207757

Forward-Port-Of: odoo/enterprise#98221