With the checkin of #10362, the code to render to a stream now looks like:

```
import { renderToStream } from 'react-dom/server'

renderToStream(<div>some text</div>).pipe(response);
```

This is great! I am, however, a little concerned about taking the word "node" out of the mix, because I'm thinking that we may eventually want to render to [**browser** streams](https://www.w3.org/TR/streams-api/), which are a really neat feature that can be used in concert with "service-worker-side rendering". I would propose renaming `renderToStream` to `renderToNodeStream` and `renderToStaticStream` to `renderToStaticNodeStream`.  This would give room for `renderToBrowserStream` in the future.

If I make a PR on this, would it have a chance of being accepted? 

cc @gaearon & @sebmarkbage 
expectMarkupMismatch(
          
          <div id="parent"><div id="child1" />      <div id="child2" /></div>, 
          <div id="parent"><div id="child1" /><div id="child2" /></div>,
        ));
      it('should error reconnecting a div with children separated by different whitespace', () =>
        expectMarkupMismatch(
          <div id="parent"><div id="child1" /> <div id="child2" /></div>,
          
          <div id="parent"><div id="child1" />      <div id="child2" /></div>, 
        ));
      it('can distinguish an empty component from a dom node', () =>
        expectMarkupMismatch(
          <div><span /></div>,
          <div><EmptyComponent /></div>,
        ));
      it('can distinguish an empty component from an empty text component', () =>
        (ReactDOMFeatureFlags.useFiber
          ? expectMarkupMatch
          : expectMarkupMismatch)(
          <div><EmptyComponent /></div>,
          <div>{''}</div>,
        ));
    });
    
    it('should error reconnecting a div with different dangerouslySetInnerHTML', () =>
      expectMarkupMismatch(
        <div dangerouslySetInnerHTML={{__html: "<span id='child1'/>"}} />,
        <div dangerouslySetInnerHTML={{__html: "<span id='child2'/>"}} />,
      ));