[Drilldowns] dashboard url param to merge filters

[Dosant]

Summary

Needed for #61219.

In drilldowns branch there is a bug with filters right now: When url to drilldown is generated and navigated to, fillers from URL always take precedence which makes sense for normal url flow, but doesn't make sense for navigation with drilldown.

This pr adds optional query param to dashboard url which allows to change default initial filters handling:
it allows instead of overriding saved filters by filters from URL merge filters from 2 sources together.

Please refer to original discussion for more context: #63108 (comment)

So options:
Option 1: retrieve saved filters in Drilldowns code. Pass all filters to url generator
Option 2: retrieve saved filters inside url generator. merge them with incoming filters when generating url
Option 3: Url generator optionally adds additional flag in the url to also preserve saved filters: e.g. &savedFilters=merge. When dashboard is loaded it will use that flag to decided what to do with filters saved in dashboard.

This pr goes with Option 3 ⬆️

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser
• This was checked for cross-browser compatibility, including a check against IE11

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: af18161

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[majagrubic]

I read the discussion in #63108 (comment) and I would recommend Option 2 here. Most of the arguments have already been laid out in there, but I just want to reiterate on arguments against it:

1. introducing a query param creates a public contract that we need to maintain
2. it's cumbersome to remove query params in the dashboard controller

As for the argument of taking care of the missing dashboard id - I think returning to dashboard listing page and displaying an error message is a perfectly acceptable flow and something we can't avoid.

[Dosant]

Will reiterate and go with Option 2