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 
textNode1 = e.childNodes[0];
            child = e.childNodes[3];
            textNode2 = e.childNodes[4];
          }
          expect(e.id).toBe('parent');
          expectTextNode(textNode1, '  ');
          expect(child.id).toBe('child');
          expect(child.childNodes.length).toBe(0);
          expectTextNode(textNode2, '   ');
        },
      );
      if (ReactDOMFeatureFlags.useFiber) {
        itRenders('a composite with multiple children', async render => {
          const Component = props => props.children;
          const e = await render(
            <Component>{['a', 'b', [undefined], [[false, 'c']]]}</Component>,
          );
          let parent = e.parentNode;
          if (
            render === serverRender ||
            render === clientRenderOnServerString ||
            render === streamRender
          ) {
            
            
            expect(parent.childNodes.length).toBe(5);
            expectTextNode(parent.childNodes[0], 'a');
            expectTextNode(parent.childNodes[2], 'b');
            expectTextNode(parent.childNodes[4], 'c');
          } else {