refactor(tour): the drop usage of overlay helper

[spike-rabbit]

The previous getOverlay function has some serious flaws. Replacing it with direct cdk usage.

See #808

Describe in detail what your merge request does and why. Add relevant
screenshots and reference related issues via Closes #XY or Related to #XY.

---

• I confirm that this MR follows the contribution guidelines.

[github-actions]

Documentation.
Examples.
Playwright report.

Coverage Reports:

• element-ng
• element-translate-ng

[spike-rabbit]

@dr-itz I removed some of the potential relevant cdk hacks you build, as I could not figure out why they are needed.
I hope this is due to the changes I did and potential cdk fixes. Please check if I missed something.

[dr-itz]

@dr-itz I removed some of the potential relevant cdk hacks you build, as I could not figure out why they are needed. I hope this is due to the changes I did and potential cdk fixes. Please check if I missed something.

well, put them back, it's completely broken now. see the demo with the open context menu. Clicking anywhere should have no effect at all, but now it does.

[spike-rabbit]

Stuff is added back again.

[dr-itz]

one nit, otherwise seems to work ok

[kfenner]

@spike-rabbit So can we delete makeOverlay and makePositionStrategy?

In the issue you state:

In most cases, the overlay-helper function can just be replaced with direct cdk calls. For tooltips and popovers a a new contextual-overlay is potentially the best approach, as those components have basically the same requirements on terms of overlay location.

I don't understand this, can we now remove the whole overlay-helper.ts or what?

Otherwise I'm a bit confused, why are we adding 66 lines and only removing 29 if we can now use cdk?

[spike-rabbit]

@kfenner yes, once I am done also extracting it for tooltip / popover, the whole overlay-helper code can be removed. But probably for v49 as we did not mark this as internal.

[kfenner]

LGTM 👍

[github-actions]