Support mu-plugins if Studio sites

[bgrgicak]

TODO:

• - move the SQLite plugin
• - move the db.php drop-in
• - remove unused code
• - ensure mu-plugins can be imported and exported
• - cli mode

Related issues

• Fixes #

Proposed Changes

Testing Instructions

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wojtekn]

@bgrgicak I think at this point, moving mu-plugins should be enough, so we could leave SQLite as is to let the user remove it and use MySQL instead.

[bgrgicak]

I think at this point, moving mu-plugins should be enough, so we could leave SQLite as is to let the user remove it and use MySQL instead.

I thought the point was to not add studio-specific code to the site.
What would users gain from us leaving the SQLite plugin, but removing other mu-plugins?

If this is about allowing users to switch between MySQL and SQLite, this could be done in the Studio UI.

[wojtekn]

I thought the point was to not add studio-specific code to the site. What would users gain from us leaving the SQLite plugin, but removing other mu-plugins?

The goal was to move polyfill plugins to mu-plugins/ directory supported by Playground to reduce confusion about why those plugins are added to the site.

If this is about allowing users to switch between MySQL and SQLite, this could be done in the Studio UI.

Currently, SQLite is the primary supported database. MySQL is not technically supported, but Studio allows user to remove the SQLite to use the MySQL of their choice.

If we add any UI for that, we should go through the project design process.

[bgrgicak]

Currently, SQLite is the primary supported database. MySQL is not technically supported, but Studio allows user to remove the SQLite to use the MySQL of their choice.

18f112a adds support for auto-switching between MySQL and SQLite.
TL;DR; if a user adds MySQL credentials to wp-config.php, wp-now won't load the SQLite extension.

[bgrgicak]

I divided this PR into two parts #845 and #847 to make it easier to test.