New File Access option breaks existing studio sites using files outside the base dir

### Quick summary

Defaulting existing sites `File access` to `Site directory` breaks them if they use files outside of the site directory. It would be better to either not break compatibility, or if the security benefits outweigh compatibility, then to detect and explain the problem to the user and how to address it.

----

I updated Studio and started a site. It looked broken (wrong theme).

The site displayed a PHP warning message about base dir restrictions stopping access to my theme files (the theme is developed in one dir and symlinked into various studio sites).

After some minutes I found `Site Settings -> File access`, changing that to `All file` fixed the problem. I was able to figure this out within a few minutes, but it doesn't mean others will be able to.

----

Apologies if this trade-off is discussed in RSM-3958 but i'm on sabbatical and don't have access.

cc @bcotrim / @fredrikekelund

### Steps to reproduce

1. Have a theme in ~/code/themename
2. Symlink it to a studio site location like ~/Studio/mycoolsite/wp-content/themes/themename
3. Activate the theme
4. Upgrade to a version of studio that contains #3786 (I assume)
5. Open the site

### What you expected to happen

I expected to see that upgrading studio meant my site continued to work as before.

### What actually happened

The theme was silently changed to TT5, and there was some warning message on some admin screens about basedir restrictions.

### Impact

Some (< 50%)

### Available workarounds?

Yes, easy to implement

### Platform

Mac Silicon

### Logs or notes

_No response_