Fix for issue #9456: decodeFront erroneously alters its input range with reference type ranges

http://d.puremagic.com/issues/show_bug.cgi?id=9456

This makes it so that `decodeFront`, `decode`, `stride`, and `strideBack` handle reference type ranges appropriately.

A related change that I'm not entirely happy about but see no way around is how `decodeFront` handles pure input ranges. In order for `decodeFront` to work, it has to pop elements at least some of the time, and pure input ranges provide no way to pop off elements without consuming them. So, either `decodeFront` can't work with pure input ranges, or it has to make sure that it consistently pops off the elements for them and never for anything else (since in all other cases, the range can be saved or a pointer is used instead of the range-based functions). And since pure input ranges of code units couldn't be decoded without `decodeFront`, I elected to make it so that `decodeFront` consistently pops of the elements for pure input ranges. Previously, the first code unit was not popped off for pure input ranges if it was a whole code point. Now it always is, so the behavior can be relied upon. Using pure input ranges with `decodeFront` is likely to be very rare though anyway. Normally, it's just used with strings.