Fix bug in HTTP/2 outbound flow control

Motivation:

The outbound flow controller logic does not properly reset the allocated
bytes between successive invocations of the priority algorithm.

Modifications:

Updated the priority algorithm to reset the allocated bytes for each
stream.

Result:

Each call to the priority algorithm now starts with zero allocated bytes
for each stream.
@Scottmitch the problem is a little more complicated than that...

It turns out that order of processing matters.  Imagine 2 streams:

 | A | B
------------ | ------------ | -------------
Priority | 255 | 1
Data | 10 | 1000

In this case the `Total Data = 1010` and `Total Priority = 256`, leaving us with a `bytesPerUnitOfWeight~=3.945`

If we scale the weight for each stream by this, we get:

 | A | B
------------ | ------------ | -------------
Bytes to Send  | 1006 | 4

If we just blindly apply this to the streams, the following will happen:

 | Sent to A | Sent to B
------------ | ------------ | -------------
Bytes Sent | 10 | 4

We could resolve this by keeping a running total of a number of bytes left over from each write and then adding it to the next stream.  In this case it will solve the problem:

 | Sent to A | Sent to B
------------ | ------------ | -------------
Bytes Sent | 10 | 4 + 996 = 1000
Remainder | 996 |

However, if we switch the order of the streams, then we still have a problem:

 | Sent to B | Sent to A
------------ | ------------ | -------------
Bytes Sent | 4 | 10 + 0 = 0
Remainder | 0 |

Maybe there's a simpler way of solving this ... I'm definitely open to alternative solutions.

But the way I solved it was:
* First, sort the streams in ascending order by their dataweight (streamable bytes * weight). The way the processing loop works, those streams appearing later in the list will be preferred.  Also, this means that any stream with no data will automatically appear first.
* Scale the weights for each stream based on the amount of data it has.  This helps to normalize the amount of data we're writing to any individual stream, so we won't try to write 1006 bytes to stream A, for example. Again, any stream with no data will automatically get a new weight of zero.
* As we write, we only subtract off the amount actually written from the remaining totals. This is essentially the remainder approach described in the example above.  It happens to work better, however, due to the scaling of the weights.

Thoughts?