delta-find: add a delta-reuse policy that blindly accepts incoming deltas When this policy is set, incoming deltas are blindly accepted without regard for the validity of the chain they build.

delta-find: add a `delta-reuse-policy` on configuration `path` That option allows to control the behavior on a per-path basis, opening the way to treating pulls from central servers differently than other operations.

changegroup: add `delta_base_reuse_policy` argument The argument available through function from changegroup.apply to `revlog.apply` allow to override the revlog configuration in terms of delta-base-reuse policy when searching for a delta to store a revision. It will be put to use in the next changesets.

bundleoperation: optionnaly record the `remote` that produced the bundle We have the information at hand, and the peer now have knownledge of its `path` object, which constaints useful behavior configuration. So the simpler seems to be to pass that object around so it can be used if needed.

delta-find: add a test checking various simple behavior There are enough work happening in this area that it is worth having a dedicated test for it. So far we add to small test checking that the "best" parent is picked as the delta base and that this behavior can be controlled during commit and unbundle.

peer: pass the `path` to the statichttp peer We now have all peer able to receive and store a `path` object. Hooray.

peer: get the `path` object down to the sshpeer Same logic as the other peers.