Add streams to releases again, include minified bundle, drop in… (#2539)

* Minify stream, add stream stuff to releases again

* Kill off a lot of tech debt, drop internal utilities from npm

1. Kill `module/`, internalize `bundler/`, privatize `test-utils/`

We've been telling people to move elsewhere from these for a while, and
it's about time we just pull the plug here and finally remove them.

- We officially removed the bundler from the public API in v2.0, and
  that was the only one of these that was ever publicly documented.
  Usage should be low enough by now it shouldn't break anyone- I'm not
  seeing bundler bugs being reported anymore, either.
- The `module/` utility was so narrow and caveat-filled that I'm not
  sure anyone really used it (even us core Mithril devs never really
  used it), and we only had it documented in the repo folder it lived
  in. I think only one bug was ever filed, and it's because it somehow
  ended up completely non-functional without any of us realizing it.
- The test utilities were meant to be internal from day 1, but people
  started using it despite us core developers constantly telling people
  to look elsewhere and even the docs recommending specific alternatives
  without mention of our internal mocks. (Now if people would RTFM,
  that'd be nice...)

2. Add dedicated HTML test files to verify ospec and the promise
   polyfill, and ensure the promise tests are in pure ES5.

These are made specially for those and should be much easier to just run
now.

3. Fix the benchmark script to use the real DOM in browsers and to not
   require as many dependencies to create. Also, tweak them to be much
   more effective and precise on what's being tested.

Previously, it was rendering to the HTML file itself, while now it's
rendering to the `body`. This means in browsers, it's triggering layout
and everything, benchmarking how well Mithril optimizes for style and
layout recalcs, too. It also puts some pressure on the hyperscript
parser attribute application, so that can be noticed as well.

* Update dependencies

docs/contributing.md

@@ -8,7 +8,6 @@
 - [Is there a style guide?](#is-there-a-style-guide?)
 - [Why do tests mock the browser APIs?](#why-do-tests-mock-the-browser-apis?)
 - [Why does Mithril use its own testing framework and not Mocha/Jasmine/Tape?](#why-does-mithril-use-its-own-testing-framework-and-not-mochajasminetape?)
-- [Why do tests use `module/module.js`? Why not use Browserify, Webpack or Rollup?](#why-do-tests-use-modulemodule.js?-why-not-use-browserify,-webpack-or-rollup?)
 - [Why doesn't the Mithril codebase use ES6 via Babel or Bublé? Would a PR to upgrade be welcome?](#why-doesn't-the-mithril-codebase-use-es6-via-babel-or-bublé?-would-a-pr-to-upgrade-be-welcome?)
 - [Why doesn't the Mithril codebase use trailing semi-colons? Would a PR to add them be welcome?](#why-doesn't-the-mithril-codebase-use-trailing-semi-colons?-would-a-pr-to-add-them-be-welcome?)
 - [Why does the Mithril codebase use a mix of `instanceof` and `typeof` checks instead of `Object.prototype.toString.call`, `Array.isArray`, etc? Would a PR to refactor those checks be welcome?](#why-does-the-mithril-codebase-use-a-mix-of-instanceof-and-typeof-checks-instead-of-objectprototypetostringcall,-arrayisarray,-etc?-would-a-pr-to-refactor-those-checks-be-welcome?)
@@ -84,14 +83,6 @@ Mainly to avoid requiring dependencies. `ospec` is customized to provide only es
 
 
 
-## Why do tests use `module/module.js`? Why not use Browserify, Webpack or Rollup?
-
-Again, to avoid requiring dependencies. The Mithril codebase is written using a statically analyzable subset of CommonJS module definitions (as opposed to ES6 modules) because its syntax is backwards compatible with ES5, therefore making it possible to run source code unmodified in browsers without the need for a build tool or a file watcher.
-
-This simplifies the workflow for bug fixes, which means they can be fixed faster.
-
-
-
 ## Why doesn't the Mithril codebase use ES6 via Babel or Bublé? Would a PR to upgrade be welcome?
 
 Being able to run Mithril's raw source code in all supported browsers is a requirement for all browser-related modules in this repo. In addition, transpiled code is generally much bulkier.