Don't tie using the XS module to whether we can load it

Change the interface for whether we use the XS module to whether you
pass a fetch callback with its fetch subroutine or not. Initially I
started writing an interface that worked like this:

    =item xs => ...

    If you provide this key and set it to a true value we'll try to use
    L<Hijk::HTTP::XS> to do our fetches, otherwise if it doesn't exist
    we'll try to use it, but fallback on a pure-perl version. If you
    explicitly set it to C<0> we'll use the pure-perl fetcher.

And was implemented like this:

    if ($args->{xs}) {
        # You said you wanted it, so you want to die if you can't have
        # it.
        require Hijk::HTTP::XS;
        $xs = 1;
    } elsif (not exists $args->{xs}) {
        # You didn't request it, but let's try to provide it.
        local $@;
        eval {
            require Hijk::HTTP::XS;
            $xs = 1;
        };
    } else {
        # You don't want the XS version
    }

    my $fetch = $xs ? \&Hijk::HTTP::XS::fetch : \&Hijk::pp_fetch;

But I thought it totally went against the minimal API of this
module. Let's just allow the user to pass in a subref instead.

This also makes it easy to wrap the existing fetching stuff in something
that e.g. times the request preparation phase v.s. the actual request
phase. I'm thinking of making use of that for the metrics of this system
I'm writing.

After building the XS module you can now run the tests with the non-XS
and XS version like this:

    for i in 0 1; do TEST_LIVE=1 HIJK_XS=$i prove -Ilib -IHijk-HTTP-XS/lib -I Hijk-HTTP-XS/blib/arch/ -I Hijk-HTTP-XS/blib/lib -r t; done

I also added a TODO to one test that doesn't throw an exception when it
should under the XS module.