[ENH] Improve the DropDownOptionsProviderBase with dynamic datas

## Enhancement Request
The Activity Descriptor API list all the activities but it can take too much time to respond when the activities have selects based on external data.

### Enhancement Overview
For our business cases, we created numerous activities that depend on dynamic data provided in select fields, allowing users to choose from options instead of using text fields, which are prone to errors.

This dynamic data comes from external APIs and varies depending on the current tenant. To provide some context, we have about 30 activities with a total of 50 select fields that rely on dynamic data.

After upgrading to version 3.3.0-rc4, we encountered a performance issue when loading the workflow definition page. The Activity Descriptor API loads all activities and their respective fields, including those with external API dependencies. Despite implementing caching for select fields with common data, the overall process still takes around 10 seconds to prepare the data.

Consequently, every time the workflow definition page is opened, it takes an additional 10 seconds to load the list of activities. While the descriptor API isn’t called again within the same browser tab, opening a new tab triggers the API, resulting in another 10-second delay.
### Alternative Solutions
We attempted an alternative implementation of DropDownOptionsProviderBase by setting the "Refresh" parameter to true, forcing the inputs to refresh when an activity is focused. In this implementation, we added a rule to make API calls only if the context is not null. This approach ensures that API calls are made only when an activity is focused, avoiding unnecessary external API calls when the Activity Descriptor API is triggered on the workflow definition page.

While this approach worked to some extent, we faced another issue: for activities with multiple select fields, some fields remained empty because they weren’t refreshed. We suspect this is due to the debouncer in the input tabs, which prevents multiple reloads. (Reference: https://github.com/elsa-workflows/elsa-studio/blob/fbb377df971cedd6e8f8e76b25f4c7ac4853474c/src/modules/Elsa.Studio.Workflows/Components/WorkflowDefinitionEditor/Components/ActivityProperties/Tabs/InputsTab.razor.cs#L31C1-L32C1).

As a temporary workaround, we added a Task.Delay in our implementation of DropDownOptionsProvider, which seems to resolve the issue by preventing the debouncer from canceling some refresh operations. However, we would prefer a cleaner and more robust fix for this case.

### Proposed Enhancement
This is an open topic, as it could impact both elsa-core and elsa-studio, depending on the chosen solution.

We are unsure of the debouncer’s specific purpose, so we are hesitant to suggest its removal. Perhaps a new refresh mechanism could be implemented specifically for dynamic data, one that is not affected by the debouncer?

### Use Cases
This enhancement would significantly improve loading times for implementations of Elsa Workflows that heavily rely on external data for their inputs.