Now that VCLs can be referenced, there are two different situations
stalling the cooldown. The "cooling" one is kept for VCLs that have
received a COLD event, and the "busy" one is introduced to wait for
ongoing transactions.

Basically, if there are transactions, the VCL is still active even
though it's not *the* active VCL and should therefore be considered
warm. This guarantees that WARM and COLD events are balanced, and
also that a "busy" VCL doesn't need to warm up if it is set to warm
again.

The new VCL temperature engine looks like this:

  .----------W>---------------.
  |              .--W>---.    v
init ---> cold --|       |-- warm --.
          ^  ^   '---<C--'    |     |
          |  |                |     |
          |  '--- cooling <C--'     |
          |         ^               |
          |         C               |
          |         |    .---<---.  |
          '--<C-- busy --|       |--'
                         '--->---'

The transitions marked with a 'W' or a 'C' are the one dispatching
WARM and COLD events respectively.

Since the "busy" state is considered warm, VMODs should operate as
such and backend creation remains possible.