Rewrite ap_byterange_filter so that it can work with data that does not

have a predetermined C-L - such as data that passes through mod_include.
Previously, these requests would generate 416 since when the byterange
filter ran, r->clength would be 0.  r->clength is only guaranteed to
be valid after C-L filter is run, but we need C-L to run after us so
that our data can have a proper C-L returned.  So, we need to rearrange
the code so that we can deal with this case.

Highlights:
- Remove r->boundary since it is possible to have this self-contained in
  boundary's ctx.  (May require MMN bump?)
- Remove call to parse_byteranges in ap_set_byterange since this would
  wrongly return -1 for dynamic responses.  We have to wait until we
  see EOS to call parse_byteranges.
- Move bound_head computation inside the num_parts == 2 check.
- Change a NULL brigade check to APR_BRIGADE_EMPTY
- Move the 416 error return to after we've run through all ranges and
  found none of them to be valid.


git-svn-id: https://svn.a...