fix(positioning): prevent memory leak in positioning service

[AurelienRichez]

While investigating performance issues on a page with a lot of tooltips, I stumbled on a memory leak in ngx-bootstrap.

Reproducer

Small reproducer creating a bunch of tooltip:
https://stackblitz.com/edit/stackblitz-starters-w3my1g3z?file=src%2Fmain.ts

steps:

1. Open the devtools memory pane.
2. important: make sure that you are looking at the preview iframe (ie the VM instance named stackblitz[something]--4200--[something].webcontainer.io). Otherwise you will only see the memory usage for the stackblitz editor itself. Alternatively you can open the preview in another tab.
3. take a snapshot of the memory
4. click the Show/Hide button a few times in the web page
5. take another snapshot of the memory
6. We can see that the memory rises up significantly even if we go back to the "hidden" state where no tooltip is rendered (to be certain of this you can also trigger a garbage collection directly in the chrome devtools, or under about:memory in firefox)

result:

Explanation

PositioningService never unsubscribes from triggerEvent$. It would be mostly harmless if there was only one instance of the service but we get one instance of PositioningService per tooltip because it is explicitly in the directive providers.

ngx-bootstrap/src/tooltip/tooltip.directive.ts

Lines 30 to 34 in 17a0f5d

	providers: [
	ComponentLoaderFactory, PositioningService
	]
	})
	export class TooltipDirective implements OnInit, OnDestroy {

I settled on simply adding takeUntilDestroyed in the service since it is less likely to have some unforeseen impact in other components compared to force the service to be a singleton.

After the change and using the same scenario the memory stays roughly equivalent between the two snapshots.

note:

I'm not sure if having several instances is intentional or not: since we have {providedIn: 'root'} I initially thought that it was a mistake and it should be a singleton, but the service also expose setOptions which makes it mandatory to have several instances if we want to have different options per component (I think #5706 is an attempt to fix that).

PR Checklist

Before creating new PR, please take a look at checklist below to make sure that you've done everything that needs to be done before we can merge it.

• read and followed the CONTRIBUTING.md guide.
• built and tested the changes locally.
• added/updated tests.
• added/updated API documentation.
• added/updated demos.

[AurelienRichez]

@lexasq I reckon you are the go-to person for review? I tried giving as much details as possible for future reference. The PR description is a bit long but I kept the code change minimal.

Tell me if you need anything else from me.