[@mantine/hooks] Focus trap identity

[Ben-Kincaid]

Fixes #4079

This addresses an edge case with useFocusTrap that can cause the cleanup function returned by createAriaHider to run after another useFocusTrap instance has operated on the same set of root nodes. This is due to the createAriaHider function being called when the callback ref returned by useFocusTrap is invoked, which will run before the cleanup function if two elements that utilize useFocusRoot are toggled simultaneously. An example of this behavior can be found in the original issue with Menu.Item/Modal: https://codesandbox.io/s/angry-rgb-x46ub2

The approach taken was to set a data-focus-id attribute to every root node that has it's aria-hidden value mutated by createAriaHider. In the returned restore function, we are then able to check if the nodes current data-focus-id attribute matches the original assigned ID. If not, we know that another useFocusTrap instance was rendered & we should not move forward with restoring the aria-hidden attributes for that given run. Additionally, a data-hidden attribute will also be added to these root nodes so that we are able to keep track of the elements initial aria-hidden state between usages of useFocusTrap.

Tests for use-focus-trap were also added, including a test case for the above scenario.

[Ben-Kincaid]

Ugh... Even though this should be totally safe in this context, need to figure out a way to suppress these warnings in the tests.

These tests must use the document body as the container element since createAriaHider uses body > :not(script) for getting the root nodes. Appending via portal also appears to throw the same warnings.

Looks like i can reassign global.console for each of the tests to avoid output, but that doesn't feel safe.

[rtivital]

https://github.com/mantinedev/mantine/blob/master/src/mantine-tests/src/patch-console-error.ts#L13

[Ben-Kincaid]

Thanks @rtivital! Just updated with the fix

[rtivital]

Thanks!