[BUG] useScrollLock - Do not leave inline styles if they weren't present before the lock

[kyrylo-soulandwolf]

Describe the bug

1. At the moment the hook leaves overflow and padding-right on the target after unlocking. Even though it is a computed value from before the lock, it can change in CSS for various reasons (and not considered in future locks) and will always be overridden by inline styles. These 2 values should be reverted to the initial value if they existed inline, otherwise removed completely which will make the styles on the target the same as before the lock.

Here's an example how tua-body-scroll-lock does this.

2. The second problem is that the global scrollbar is not part of the body, so if lockTarget is a body element scrollbarWidth will always be 0. There should be a special case for body as a target and use window.innerWidth instead of target.current.offsetWidth to get the width with the global scrollbar.

To Reproduce

Codesandbox repro link

1. Just lock and unlock any element.
2. Same thing but using body as a target

Expected behavior

After unlocking, the target element should have initial inline styles or no inline styles if they weren't present.

Additional context

No response

[kyrylo-soulandwolf]

The tests seem to pass by returning false positives because window.getComputedStyle(...) returns an empty string instead of the actual value

[kyrylo-soulandwolf]

Opened a pull request #521 😊