Specify initial ring buffer contents when rolling

[cole-miller]

As discussed in #11, requiring the ring buffer to be zeroed means that checksum values emitted before W bytes have been consumed are fully determined by the input data, so there's no need to protect callers of the hashsplitting routine by disallowing splitting in this region.

Closes #11

[zenhack]

Hm, this doesn't really do what was intended, since it doesn't touch the declarative description of the hash function, only the implementation notes; the way the declarative version is described still doesn't define what the hash would be for a a window that started in the negative.

As an aside, perhaps we should explicitly mark sections of the spec as "normative" or "non-normative"; this language is used by some standards bodies to indicate whether a section is prescriptive in terms of conformance or just additional guidance. In this case the "Implementation" section is non-normative, since it's intended to provide guidance to implementers, but doesn't authoritatively define the function.

I think if we were to stick with the constraint W <= S_min, the implementation section might be a good place to spell out why, as it has implications for that.

[cole-miller]

Hm, this doesn't really do what was intended, since it doesn't touch the declarative description of the hash function, only the implementation notes

Yep, this was my oversight. It should be repaired now.

I don't have a strong opinion about splitting normative from non-normative language.

[zenhack]

Merged this locally and tacked on a commit that adds a 'non-negative' constraint to i (since a negative i is possibly defined now, depending on the hash function...). Thanks!