Add ability to expose require() with standalone.

[jmm]

Designed to fix #45. This sets up the ability to opt-in to exposing a require() when bundling in standalone mode, like this:

browserify({standalone: 'whatever'})
  .require('entry', {expose: 'whatever'});

EDIT: also see below for an alternative implementation.

Standalone without .require(..., {expose: ...}) and vice versa work pretty much like currently.

Constructive criticism appreciated.

TODO:

• Some fine tuning may be in order depending on the answer to Is exposed name from b.require() supposed to be available inside bundle? browserify#1137.

• The expose value passed to require() should probably be coerced in similar fashion to the coercion UMD does on the standalone value. Breaking out and exposing some additional functions in ForbesLindesay/umd may make sense for that. Probably better yet would be to give the user the option to use either the coerced value or the verbatim value they pass.

• I have a new test on browserify for this. Are there new tests here that would make sense? (EDIT: tests for browser-unpack for one, I think.)

• If the user does:

  browserify({standalone: 'whatever'})
    .require('entry');

  • Just let the require() with automatically generated expose key be exposed?
  • Document that that usage will result in a require() being exposed?.
  • Should browserify even be exposing in that case?
  • Only expose require() if row.expose === opts.standalone?

[piranna]

Just let the require() with automatically generated expose key be exposed?

I suppose yes. What's the current behaviour for require()?

[jmm]

I suppose yes. What's the current behaviour for require()?

I think that is the current behavior, but I'm not sure it should be. I want to look into it sometime.

[jmm]

There need to be some tests here for browser-unpack don't there?

[jmm]

Here is an alternative implementation that changes the source and output less. In either case I think browser-unpack will need a little adjustment.