[react devtools] Device storage support

[rbalicki2]

Summary

• This PR adds support for persisting certain settings to device storage, allowing e.g. RN apps to properly patch the console when restarted.
  • The device storage APIs have signature getValue(string) and setValue(string, string), and are thin wrappers around the Library/Settings turbomodule.
• Pass device storage getters/setters from RN to DevTools' connectToDevtools. The setters are then used to populate values on window. Later, the console is patched using these values.
• If we receive a notification from DevTools that the console patching fields have been updated, we write values back to local storage.
• See [react devtools] Pass a CachedSettingsStore to connectToDevTools react-native#34903

How did you test this change?

Manual testing, yarn run test-build-devtools, yarn run prettier, yarn run flow dom

Manual testing setup:

React DevTools Frontend

• Get the DevTools frontend in flipper:
  • nvm install -g react-devtools-core, then replace that package with a symlink to the local package
  • enable "use globally installed devtools" in flipper
• yarn run start in react-devtools, etc. as well

React DevTools Backend

• yarn run build:backend in react-devtools-core, then copy-paste that file to the expo app's node_modules directory

React Native

• A local version of React Native can be patched in by modifying an expo app's package.json, as in "react-native": "rbalicki2/react-native#branch-name"

Versioning safety

• There are three versioned modules to worry about: react native, the devtools frontend and the devtools backend.
• The react devtools backend checks for whether a cachedSettingsStore is passed from react native. If not (e.g. if React Native is outdated), then no behavior changes.
• The devtools backend reads the patched console values from the cached settings store. However, if nothing has been stored, for example because the frontend is outdated or has never synced its settings, then behavior doesn't change.
• The devtools frontend sends no new messages. However, if it did send a new message (e.g. "store this value at this key"), and the backend was outdated, that message would be silently ignored.

[rbalicki2]

@lunaruan This is basically the same as the previous (approved) PR. I just had to recreate it, because I deleted my fork and recreated my fork, and can no longer amend that PR.

The difference is that getValue and setValue now take a key parameter, because the underlying implementation is an existing K/V store (it exists!).