gdb: add osv load-elf command

Sometimes one needs to load external ELF file which loader.py cannot
find automatically. For example when running an application which is
built outside OSv.
gdb: implement __bool__ which is required by python3

What was __nonzero__ on python2 is now __bool__ on python3. This
change fixes an issue with "osv info threads" which printed a line
starting with "timers:" even if there were no timers.
core: introduce bitset iterators

They allow for concise iteration over indexes of set bits:

for (int index : for_each_set(my_bitset)) {
    ...
}
core: introduce efficient timer_set data structure

The data structure optimizes for timer non-delivery by deferring
sorting cost until expiry time. The optimization is based on the
observation that in many workloads timers are cancelled or rescheduled
before they expire. That's especially the case for TCP timers.

The algorithm was originally proposed by Avi.

The idea is that we spread timers into buckets based on the length of
the common bit-prefix between timer's expiry time point (aka timeout)
and the last expiry time point (_last). The timer whose timeout is >=
_last and has no more than N trailing bits the same as _last lands in
bucket N. When we expire at time point "_now" we calculate the prefix
index between _now and _last which we will call "e_index". We don't
need to consider buckets in indexes lower than e_index, they don't
fire yet and their index won't change when base is switched to
_now. Timers in buckets with indexes higher than e_index are all known
to have just expired. Finally, we need to walk through all timers
inside bucket e_index and check if they have expired or not. If timer
from bucket e_index is not expired we need to re-hash it using the new
base time point.

 == Computational complexity ==

The cost of insert() and remove() is always O(1). The cost of expiry
is more complex. It depends on the distribution of timeouts.

Best case is when all timeouts expire at the same time. Then the cost
of expiring timers is O(1) - all timers are expired in one loop over
the bucket in which they reside.

The worst case is when all timers land in the same bucket after each
expiry, in which case the expiry cost per timer is O(N). We hit this
cost when timeouts are laid out like this:

 t1    = 11111
 t2    = 11110
 t3    = 11100
 t4    = 11000
 t5    = 10000

 _last = 00000

All timers land in bucket 0. After expiry with _now = 10000, we will
have to check the whole bucket 0. After expiry we have:

 t1    = 11111
 t2    = 11110
 t3    = 11100
 t4    = 11000

 _last = 10000

All timers are now in bucket 1. And so on. The worst case presented
above is unlikely.

Let's consider a more typical case when timeouts are spread evenly
over some range (A, B), eg:

 1000
 1001
 1010
 1011
 1100
 1101
 1110
 1111

Initially they are all in one bucket, but after each expiry the
remainder of timers is split into 2 buckets. Therefore the total cost
of expiring N timers is O(N * log(N)), so per-timer cost is O(log(N)).
tests: add test for timer_set
core: switch async timers to use timer_set
core: make sched::timer_list use timer_set
core: avoid unnecessary reschedules

sched::timer_list is tracking last time point the clock was set in the
_last field. It seems to be an optimization which would prevent clock
sets when timers are repeatedly cancelled and set. This field is
updated by rearm() method. timer_list::resume() was not using that
method, which could leave _last with a stale value.

Spotted during code inspection.
core: use unordered_queue_mpsc for released_timer_tasks

The unordered_queue_mpsc burns a bit less cycles than queue_mpsc and
will suffice in this case.