Separate module options from test environment

Related:

• https://github.com/jquery/qunit/issues/894#issuecomment-158127790
• https://github.com/jquery/qunit/pull/919/files#r51184320
• https://github.com/jquery/qunit/pull/800#issuecomment-139293379

Note that there are two ways to set before/after hooks (which are currently the only module options): as properties on an options object, and as methods on the argument passed to a callback. Exposing environment procedurally is easy (e.g., a writable environment property on the callback argument), but the declarative side makes backcompat tough. I'm not particularly thrilled with the thought of adding a fourth parameter, though... we could instead look for an environment property on the second argument, using it exclusively when present (technically backwards incompatible, but on the same scale as #919) and otherwise generating warnings whenever there's any non-before non-after property. All of which, of course, is assuming that keeping the declarative/procedural duality is valuable, about which I'm not fully persuaded but am inclined to keep for now (in part since the procedural interface is so new).

For example, all of these would generate the same environment for their tests:

QUnit.module(name, {
    beforeEach: function() {…},
    environment: { preserved: true },  // new
    ignored: true
});

// Define tests
…

QUnit.module(name, function( hooks ) {
    hooks.environment = { preserved: true };  // new
    hooks.beforeEach(function() {…});

    // Define tests
    …
});

QUnit.module(name, {
    beforeEach: function() {…},
    // For compat with current QUnit (if no environment is defined).
    preserved: true
});

// Define tests
…

But the last would issue warnings about deprecated options/environment mixing.

I'm not in love with this, but it's the best I've got. Other suggestions welcome.

Start by reading the linked discussion in issues #894 and #919 and the referenced pull requests, then compare the declarative and procedural examples in this issue. The work is not ready to implement until the module-options API, backward-compatibility behavior, and warning conditions are agreed; done would include tests covering the settled behavior.