Consider adding `end_inclusive()` method and documenting inclusitivity of HTTP's range ends

[LukasKalbertodt]

I just tracked down a bug with my Range HTTP server that was caused by this:

            .header(header::CONTENT_RANGE, format!(
                "bytes {}-{}/{}",
                range.start,
                range.start + range.length,
                file_size,
            ));

The error is in the addition: it is missing a - 1, since the header expects the end of the range to be inclusive (same for the Range header). Of course, this bug is not this library's fault. But I wonder if this library could help users avoid this. Having a range end's be inclusive is quite counter-intuitive, especially for Rust developers where the standard range a..b has an exclusive end.

Maybe it's a good idea to add methods to HttpRange, like fn end_inclusive(&self) and fn end_exclusive(&self)? Before I wrote the addition, I checked if there was a method and I would have used it if there was. And if both of these methods were present, it likely would have alerted me to the possibility that the header might not expect an exclusive end.

As another bonus, this moves the -1 into a method. Such a - 1 usually raises my alarm due to the potential of underflow in certain situations. The - 1 is fine here, as by the nature of the inclusive end, the length is always at least 1. But having this encapsulated in the library would be nicer.