Browser-support for jshttp (and maybe other) modules

from https://github.com/jshttp/content-type/pull/7#issuecomment-200635582 and from the TC meeting w/ @wesleytodd

my thoughts:
- UMD code should never be committed to GitHub (except as releases, maybe). UMD code should be built with a `prepublish` step.
- there must be tests for browsers. a discussion of alternatives would be welcomed.
- we only support browsers we test
- phantomjs is acceptable as a first step, but it's not a browser, so we can't claim browser support
- saucelabs is not very reliable, so i prefer not to use it
- i hate selenium and i don't think it's relevant
- substack's service is deprecated, which would've been nice and easy

my questions:
- if you do not use webpack/browserify/npm/etc, how would you be consuming these?
- would you consume UMD builds with GitHub releases?
- do we want to support bower? (please no)
- do we want to include all the dependencies in the UMD builds? this would be necessary for `` tag users, but not bower users
- do we want to run our code through `babel`? this will allow including polyfills and/or
- what type of support are you looking for in browsers other than `browserify module + tests -> running in the browser`? i'm sure there are some edge cases, maybe polyfills like `setImmediate()` support.
- would we want to push updates to CDNs like CDNJS?
- how much effort do we want to put into these modules so that they aren't bloated for the browser?
- for example, loading `mime-db` in the browser might be excessively large

going forward, i'd like to build a sample repo for standardizing all modules including (most of which is already pretty standardized thanks to @dougwilson):
- readme (AND BADGES :D)
- package.json
- linting
- node.js tests
- browser tests

if we all agree on it, i don't mind making the PRs for a lot of the modules to make them all consistent