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 
expect(e.childNodes.length).toBe(3);
          expectTextNode(e.childNodes[0], 'foo');
        }
      });
      itRenders('only null and false children as blank', async render => {
        const e = await render(<div>{false}{null}{null}{false}</div>);
        expect(e.childNodes.length).toBe(0);
      });
    });
    describe('elements with implicit namespaces', function() {
      itRenders('an svg element', async render => {
        const e = await render(<svg />);
        expect(e.childNodes.length).toBe(0);
        expect(e.tagName).toBe('svg');
        expect(e.namespaceURI).toBe('http:www.w3.org/2000/svg');
      });
      itRenders('svg element with an xlink', async render => {
        let e = await render(
          <svg><image xlinkHref="http:i.imgur.com/w7GCRPb.png" /></svg>,
        );
        e = e.firstChild;
        expect(e.childNodes.length).toBe(0);
        expect(e.tagName).toBe('image');
        expect(e.namespaceURI).toBe('http:www.w3.org/2000/svg');
        expect(e.getAttributeNS('http:www.w3.org/1999/xlink', 'href')).toBe(
          'http:i.imgur.com/w7GCRPb.png',
        );
      });
      itRenders('a math element', async render => {