has_next* methods corresponding to each next* method

[hxtk]

The design problem associated with this is that we must be able to look ahead without consuming.

As the current version makes no guarantees about tokens that do not fit in a single input buffer, we can simply examine the buffer itself. In the future, however, it will be necessary to read multiple buffers of information without consuming them.

However, BufRead.fill_buf() will happily return the same buffer over and over again if you do not consume in between.

[hxtk]

So the basic algorithm is the same one we use in next() except without consuming. It seems sensible to try to export the "meat" of next into a private helper function that serves both of these.

[hxtk]

The first thing next() does is consume leading inputs. Using this for has_next would break the unit test for next_preserves_trailing_delim. Step one is to rewrite consume_leading_delims() to return an offset instead of performing an action.

[hxtk]

next_line doesn't rely on next, so it doesn't follow the new rules.

However, we can implement has_next_line as a special case: if stream has_next, stream has_next_line.