Clarify non-fatal React Native DevTools preparation errors

[Cedric921]

Summary:

Addresses #54906.

When preparing the standalone React Native DevTools shell throws, the dev server prints:

ERROR  An unknown error occurred while installing React Native DevTools.. Details:

This shows up, for example, on some Linux setups where the Electron binary fails to launch (see the LaunchProcess: failed to execvp reports in the issue). As @huntie noted in the issue, this isn't fatal: /open-debugger falls back to opening the debugger in a browser window. The message reads like a hard failure, though, and it also ends with a doubled period.

This PR:

• Gives the catch-all unexpected_error result from unstable_prepareDebuggerShell a humanReadableMessage saying that a fallback is used, consistent with the messages for the other failure codes in LaunchUtils.js.
• Logs unexpected_error as a warning in createDevMiddleware, like the other non-fatal codes (likely_offline, platform_not_supported, possible_corruption), and removes the duplicated trailing period.

It does not address the underlying Linux launch failure (the binary path containing spaces). That fix belongs in the prebuilt DevTools packaging.

Changelog:

[GENERAL] [CHANGED] - Report unexpected React Native DevTools preparation failures as a non-fatal warning that mentions the fallback

Test Plan:

Added:

• packages/debugger-shell/src/node/__tests__/prepareDebuggerShell-test.js: the catch-all path returns a humanReadableMessage.
• A preparation failure logging case in StandaloneFuseboxShell-test.js: an unexpected_error is logged via logger.warn (not logger.error) and includes the fallback message and the verbose details.

Both new tests fail without the change and pass with it.

yarn jest packages/dev-middleware packages/debugger-shell
Tests:       146 passed, 146 total

yarn flow full-check   -> Found 0 errors
yarn eslint            -> clean
yarn prettier --check  -> clean for changed files

[vzaidman]

Hey! Thanks for the PR.
I think that unexpected errors ARE fatal and should log an error. However this one should indeed log a warning, so it probably should not be unexpected_error. See if there's an existing error we can throw in this case, and if not- create a new one.