GAUD-10062: expose waitForElem

[dlockhart]

In somewhat rare circumstances, changing a component's state can cause a totally different set of components within it to render. One example might be putting it into an error state. When this happens, awaiting updateComplete isn't often enough, as those new nested components might have language terms that need to load or they may need to do their own asynchronous work.

To solve this, we expose waitForElem -- which is already used internally by the original fixture call.

[dlockhart]

I've also flipped the order here. We first wait for getLoadingComplete and then we wait for updateComplete. The reasoning here is that almost always getLoadingComplete resolving is going to trigger some kind of state change, so we wait for updateComplete after that.

[dlockhart]

While I was here...

[bearfriend]

Should we be concerned that the waitUntil is actually the thing delaying long enough to make the expect pass? Can we use hasChanged or an event instead? Does setting slow on the original fixture not hold waitForElem until everything is done?

Suggested change

	elem.slow = true;
	const waitPromise = waitForElem(elem);
	await waitUntil(() => resolves.has('slow'));
	timeouts.push(setTimeout(() => resolves.get('slow')(), 50));
	await waitPromise;
	expect(elem.shadowRoot.querySelector(slowElem).finished).to.be.true;
	const waitPromise = waitForElem(elem);
	elem.slow = true;
	await waitPromise;
	expect(elem.shadowRoot.querySelector(slowElem).finished).to.be.true;

Like waitPromise is never going to resolve before elem.slow is set, and then that would kick off the update cycle and should hold the await until finished is set... I think.