feat: Export getDevServer function as public API

[natew]

Summary

Exports the getDevServer function and DevServerInfo type from React Native's public API, making them available without deep imports.

Motivation

Deep imports are deprecated in v0.80 and will be removed in v0.82. Library authors currently rely on internal imports to use getDevServer:

// Current (deprecated)
import getDevServer from 'react-native/Libraries/Core/Devtools/getDevServer'

// After this PR
import { getDevServer, DevServerInfo } from 'react-native'

Use Cases

• HMR clients: Tools like vxrn use getDevServer() to establish WebSocket connections to the dev server for hot module replacement
• Dev tooling: Libraries need to know the dev server URL for error symbolication, bundle loading, and debugging features
• URL resolution: Getting the base URL for fetching assets and making requests to the packager

The function is already used internally by React Native for:

• symbolicateStackTrace.js - Error stack symbolication
• loadBundleFromServer.js - Dynamic bundle loading
• openFileInEditor.js - Opening source files in editor
• React DevTools connection setup

Changelog:

[GENERAL] [ADDED] - Export getDevServer function and DevServerInfo type from public API

Test Plan

This is a straightforward export addition. The function already exists and is well-tested internally. Consumers can now import it directly:

import { getDevServer } from 'react-native';

const { url, bundleLoadedFromServer } = getDevServer();
console.log('Dev server URL:', url);

[huntie]

Hey @natew!

Gut reaction here is I don't think we want to expose these on the public 'react-native' import path. However, there is scope to put these under a new 'react-native/devsupport' (or potentially '@react-native/devsupport') entry point, which is being considered (or at least I am planning to open an RFC for soon enough). This PR adds extra motivation for that design.

It should be fine for your library to continue to use this subpath export for the forseeable future (note that these warnings will not propagate to consuming apps). We missed the 0.82 target as the community needed more time, and indeed we had extra APIs to solve, like the above plan.

Please stay tuned 🙏🏻