Add support for inherited param handlers

This is a first cut at inherited param handlers. Likely this comes with corner cases, as I'm not an express internals expert, but it appears to work in straightforward cases. An additional parameter for `Router` is introduced to control this behavior:

```javascript
var router = express.Router({ inheritParamHandlers: true });

app.param('user', function (req, res, next, id) {
  User.findOne(id, function (err, user) {
    if (err) return next(err);
    req.params.user = user;
    next();
  });
});

router.param('photo', function (req, res, next, id) {
  Photo.findOne(id, function (err, photo) {
    if (err) return next(err);
    req.params.photo = photo;
    next();
  });
});

router.post('/update-tags/:photo', function (req, res) {
  // Error: contrived example
  req.params.user.update(req.params.photo, req.body, function (err) {
    if (err) return res.status(500).json({ status: 'error', error: err.message });
    return res.status(200).json({ status: 'updated' });
  });
});

app.use('/users/:user', router);
```

I've made it separate from `mergeParams`, as this may cause unexpected behavior for users if enabled via that option. However, it does enable `mergeParams` implicitly if used. A case could be made to consolidate the two into a single option which always does both as `mergeParams` was only publicly documented recently so perhaps the exposure is small.

The parameter handlers are kept in the `Router` but now follow the request throughout the `_router.handle()` path. This *should* allow different behavior if a router is attached to different apps or paths.

This would address issue #2151.
I mean, otherwise the actual implementation is fine. The who alternative router thing is because there will soon be different router implementations to choose from with express, including one that supports promises for those who like that, and they should be able to be mixed-and-matched.