Throttle panel repaints
Throttle panel repaints

Multi-file reporters usually broadcast many new errors in one go, t.i. within
the same task/tick e.g. in a for loop. Although painting the panel is fast
enough, too many repaints just look bad. We also cannot guarantee that the
scroller scrolls 100% to the correct position. This is usually the case when
scrolling is animated because measuring the viewport/scroll position during
an animation leads basically to intermediate results.

So we implement a throttler.

Broadcasting errors should always happen (from the caller site) on the worker
thread. Painting new content must always happen on the main thread because we
cannot hold the viewport stable otherwise. So prior to this commit broadcasting
and painting was ordered but parallel:

    |--------------|  # broadcast lint results (worker)
      |a  |b  |c      # queue draws
      |    \   \_
      |     |    \
      |-----|-----|-----  # run draws (main)

This PR uses the worker thread for scheduling draws. If multiple draws for the
same panel land in the queue, only the most recent will survive and actually
run. Prior requests get evicted.

    |--------------|  # broadcast lint results (worker)
      |a  |b  |c      # schedule/request draw
       \___\___\______
                  \ \ \
    |--------------|a|b|c     (worker)
                    | | |
                    x x |-----  # run draws (main)

+ We don't throttle using time spans.
- We're always a bit slower than before. Actual performance depends on how busy
  the worker is.

Opportunities: a) Maybe we can teach the broadcaster to emit the most important
errors, e.g. the errors from the active view, first. b) We could always draw
immediately if the originating event was about the current file.

SublimeLinter/SublimeLinter3,SublimeLinter/SublimeLinter3