Improve potentially misleading DCP producer end stream log message

The DCP producer end stream message looks as follows:

Fri Apr 15 12:52:22.294840 PDT 3: (default) DCP (Producer) eq_dcpq:mapreduce_view: default _design/scale (prod/main) - (vb 990) Stream closing, 0 items sent from disk, 8 items sent from memory, 95232 was last seqno sent The stream ended due to all items being streamed is the reason

Which looks reasonable enough. However, it turns out that the last sequence number sent is not the last sequence number that will be sent as part of the snapshot, it's the last sequence number sent at the time the end stream message is added to the queue. This is misleading or at best confusing when one is debugging issues. In the case of this particular end stream message shown above, for this particular snapshot we reported the stream creation as follows:

Fri Apr 15 12:52:22.294299 PDT 3: (default) DCP (Producer) eq_dcpq:mapreduce_view: default _design/scale (prod/main) - (vb 990) stream created with start seqno 95216 and end seqno 95232

However, we had sent a snapshot marker at the beginning of the stream which the client (view-engine) reported as follows:

[couchdb:info,2016-04-15T12:52:22.295,ns_1@172.23.105.63:<0.20508.455>:couch_log:info:41]set view `default`, main (prod) group `_design/scale`: received a snapshot marker (in-memory) for partition 990 from sequence 95216 to 95235

So it looks like we were requested to open a stream up to 95232, rounded this value up to 95235 (and sent a snapshot marker indicating this) but when the stream was closed we reported 95232. Either we did close at 95232 (which would be bad since we should finish on a snapshot boundary) or we actually sent to 95235 (but then the stream end error message should reflect this.)

Thinking about it, it would be nice to reflect the "rounding up" to the snapshot boundary in the stream creation message too, if it's easy to do.