fix: Disable cross-frame focus lock in <Modal>

[pawelgrimm]

Short description

When using <Modal> in a Storybook story, controls would stop working. This was determined to be caused by the <FocusLock> component, which would prevent interaction with Storybooks preview/add-ons pane once focus was established within the modal (which would happen automatically as autoFocus defaults to true). To fix this, we're limiting <FocusLock>'s focus trap to the document/iframe the Modal is contained within, preventing it from bleeding over into Storybook's preview pane.

PR Checklist

• Added tests for bugs / new features
• Updated docs (storybooks, readme)
• Executed npm run validate and made sure no errors / warnings were shown
• Described changes in CHANGELOG.md
• Bumped version in package.json and package-lock.json (npm --no-git-tag-version version <major|minor|patch>) ref
• Reviewed and approved Chromatic visual regression tests in CI

Versioning

[pawelgrimm]

@gnapse @frankieyan Do you forsee any issues with this approach? It's been a LONG time since we last touched this code (#591 (comment)), but I thought I'd check with y'all.

[frankieyan]

I just realized that the focus lock is actually causing problems for us right now

If you open up a template's task detail in https://todoist.com/templates/todoist-ceo-setup (you'll have to use a browser window without a Todoist logged in session), and once you focus on its elements, you cannot focus on any of the host page's elements anymore, similar to what we're seeing in Storybook.

While we do allow Todoist to be embedded (we have no X-Frame-Options header), I'm not aware of any situations where we'd want to take over control from the host page, so I'd imagine this change to be safe to make 👍