Improve quic:stream_data_moved

[rmarx]

As reported by @hlandau on the mailing list:

quic:stream_data_moved:

A brief explanation of each from/to value here and the intended meaning would be a big improvement. Also clarify that raw here refers to the referenced stream application data (and does not include frame headers etc.).

Consider having a way to report when the end-of-stream (FIN) condition is reported to an application. One option here is to have an optional "fin" field here.

There does not appear to be any way to communicate when a stream reset event is delivered to an application in an equivalent way, which would be useful.

quic:datagram_data_moved:

As with stream_data_moved, clarify meaning of the from/to fields here.

[rmarx]

While I can do the first part here (explain the from/to intents), I think @LPardue is more qualified to help with how we best indicate other signals have been delivered from transport to application.

I know that has a long history of discussion in general, and I personally don't think this should be part of the data_moved event (i.e., would need a new event in my opinion)

[LPardue]

There's already a lot of text in these sections, personally I don't think explaining each field is going to be much more help.

Re: raw raking it clear it is stream data not frames is a couple of words and worth it.

I can see some value in the ability to indicate when an app requests a stop_sending or a reset_stream or when either is passed up to an app. I think that's a new event though.

For stream fin, I could argue a few ways. I think a ? fin: bool field on stream_data_moved is probably the best tradeoff.

[rmarx]

Discussed in editors meeting. Robin: not the biggest fan of adding fin + some additional fields for stop_sending and reset_stream, but option. Marten and Lucas: similar APIs in implementation: fin is possibly separate from the others (which are passed as errors). Errors often don't get communicated directly when happen, but only when application tries to read. So it does make sense to have it in stream_data_moved maybe. Lucas: will propose a PR to add these signals to stream_data_moved