A previous fix went in to make sure the reply draft banner would hide

when deleting comment replies, but it unconditionally hid after any

reply was deleted, even if it wasn't the last one on the review.
This fixes the problem by changing how some of this code works. There's

now only one place that controls the showing/hiding of the banner, which

uses the "hasDraftChanged" signal emitted by the view. The places

managing the banner were previously emitting this and also changing the

banner state, so now they only have to concern themselves with the

signal.
The major part of the fix involves tracking how many drafts there are on

the review. This is computed on render and as reply editors go in/out of

draft state. When there's no editors left, the banner is hidden.
Ideally, much of this logic and state would live in a model, but we're

currently using RB.Review as the model for this view. A future change

can simplify a lot of this by separating out much of the logic, state,

and signals.

Loaded a page with a reply banner and two draft comments. Saw through

debugging output that it had the proper count. Deleted a reply, saw the

new count and saw that the banner remained on page. Deleted one more and

saw that the banner went away, with a count of 0.
Added a new reply and saw the count and the banner appear. Deleted and they

both reset.
Unit tests passed.