[select] Forced reflows / Layout trashing

In #3531, we made the "style computation" step of the rendering pipeline x10 slower. This made it pretty obvious **where** we were doing inefficient DOM reads from the Select component. We compute the styles x3 while we only need it to do it once?

We fixed the expense style computation for our docs, but what about other people's websites? They might have CSS selector-heavy pages, but we can't control this.

## Current behavior

1. Open https://693ae9e6a41ca30008471aaf--base-ui.netlify.app/react/components/select
2. Open the select
3. See the 3 forced layout read that happens on 3 different frames

### First one

Coming from https://github.com/floating-ui/floating-ui/blob/0681dbb620ca78492f0acf289987151fbca7f0b0/packages/dom/src/platform/isRTL.ts#L4, which seems to be a misuse of Floating UI's API on the Base UI side, since with #831 we purposefully said we wouldn't read the DOM to know RTL, and Floating UI allows us to take this information in.

### Second one

Coming from https://github.com/focus-trap/tabbable/blob/26a1d80b616a41bfd21960a0065b3188e58c47b0/src/index.js#L432, which seems to be yet another (first 1 is [bundle size](https://bundlephobia.com/package/tabbable@6.3.0), it can be /10 smaller, 2nd one is unreliability, browsers have all custom ways to handle this) downside of not using the Material UI's focus trapping approach. Arguably, you could say, there is nothing to do, simply batch with ⬇️

### Third one

Coming from https://github.com/mui/base-ui/blob/650b61ad7791ffc2a569c124873f36c7744a1162/packages/utils/src/useScrollLock.ts#L74, which seems to be a timing issue, why does it happen in a different frame?

## Expected behavior

Batch all the DOM reads into the same frame.

## Base UI version

v1.0.0

## Which browser are you using?

Chrome