stbt-power: Use the HTTP interface of PDUeX units

The PDUeX KWX device provides three interfaces:
- SSH: The one used so far; very slow (it takes up to 20 seconds to
  execute a command) and we are experiencing PDU lock-ups during high
  load.
- Telnet: It's fast, but doesn't accept multiple simultaneous client
  connections.
- HTTP: Fast and handles concurrency.

Considering the above mentioned pros and cons, it's worth switching
to HTTP.

This commit changes the output format:
- 'on' and 'off' commands don't output anything unless there is an error;
- 'status' only prints "ON" or "OFF" if the individual power outlet is
  specified;
- or "<outlet>: ON|OFF" with the status of one outlet per output line if
  all outlets are queried.

IMPLEMENTATION ISSUES

1. AUTHENTICATION

The first HTTP request sent to the PDU from a client is rejected with
error "401: Unauthorized". A follow-up request has to be sent to the
server to perform basic access authentication. Therefore, a "dummy"
request precedes every command sent to the PDU.

2. FAILED REQUESTS

Stress-tested the PDU with 8 simultaneous HTTP requests sent every ~10
seconds for 64 hours. The device did not lock up, but out of ~300000
on/off requests 104 failed, that is, ~0.04 % of all HTTP requests.

To minimise the number of failures, every 'on' and 'off' request is sent
to the PDU up to three times, allowing 2 ignored requests per `stbt power`
execution. If the 3rd request fails, `stbt power` exits with status code
1. In theory this reduces the failure rate to virtually zero.

3. TIMING

Measuring execution time showed that the PDU requires up to 1
second per outlet to execute a command, i.e. the status of the
outlet changes within 1 second if 1 command is sent, but it may
take 8 seconds if 8 simultaneous commands are sent.

As the PDU doesn't send response to 'on'/'off' requests, the status of
the outlet is queried to verify the outcome of a command. To save time,
status requests are sent every second up to 8 times; if the 8th
response doesn't include the expected status, the 'on'/'off' request is
resent.

4. HARD-CODED IDENTIFIERS

It is assumed that an individual outlet address is always in the format
'1-An' where 'n' is the number of the individual power outlet in the
range 1 <= n <= 8. We need to have this assumption because 'on' and 'off'
HTTP requests don't include the outlet address, only the outlet number;
however we need to know the outlet address to parse the status response.

It is also assumed that the default user name and password 'admin:admin'
haven't been changed on the PDU unit.

5. REDUNDANT STATUS REQUESTS

To keep implementation simple, querying the status of all individual
outlets sends 8 identical requests. Even though a single response
includes the status of all outlets, I'd find this solution acceptable
in favour of less code, as this is a seldom used command: we always
specify an individual outlet.