README.rst: Update subtitle to match description on stb-tester.com

I made a similar change to the description of the RPM package in
commit fde36144.
Makefile: Build stb-tester.rpm
stbt power: Support ATEN network-controlled PDU's

This commit implements support for ATEN PDU's over SNMP. While these
PDU's also have a web interface, SNMP is a more direct and reliable way
of controlling them. It also updates the regex to recognise the `aten`
as a valid model. To query and control the PDU, it makes use of the
`snmpget` and `snmpset` commands from Net-SNMP [1]. The packaging
scripts were updated to install these tools as dependencies [2].

The relevant SNMP OID's were found using ATEN's MIB file v1.1.109 [3],
which applies to *all* ATEN PDU's:

    outlet1Status  enterprises.21317.1.3.2.2.2.2.2.0
    outlet2Status  enterprises.21317.1.3.2.2.2.2.3.0
    outlet3Status  enterprises.21317.1.3.2.2.2.2.4.0
    ...            ...
    outlet42Status enterprises.21317.1.3.2.2.2.2.44.0

Each outlet status is an integer in the range 1-8. From the MIB file:

    Display and control outlet status. Can't set pending status.

    Enumerations:
    1 - off
    2 - on
    3 - pending
    4 - reboot
    5 - fault
    6 - noauth
    7 - not-support
    8 - pop

When querying the outlet status through `stbt power status`, this
implementation maps values 1->OFF and 2->ON.

Even though sending an ON or OFF command through SNMP returns
immediately, the outlet can take some time to complete the transition.
However, this implementation will poll until the outlet actually
achieves the desired state and will exit with an error if it fails to do
so within the timeout interval (12 seconds) [4]. Note that during the
transition period the outlet will return its status as 3 (pending) but
this state should never be visible to end users of `stbt power`.

The Net-SNMP commands use SNMPv2c because it is faster than SNMPv1 and
unlike SNMPv3 it doesn't require authentication (which would also be
slower).

When `snmpget` or `snmpset` operate on an OID that is not known to the
device, they do not fail with non-zero status but instead print: "No
Such Object available on this agent at this OID". In stbt-power this
should only happen if (1) the device is not an ATEN PDU or (2) the
outlet was specified incorrectly (non-integer, less than 1, or greater
than the device's number of actual outlets).

Note that the SNMPv2 read & write community is hard-coded to
"administrator", which is the default on ATEN PDU's.

This was tested on an ATEN PE6108G 8-outlet PDU and Net-SNMP v5.7.2.

[1] http://net-snmp.sourceforge.net/docs/man/
[2] Debian package `snmp` and Fedora package `net-snmp-utils`
[3] http://www.aten.com/export.php?mid=20130906165112002&type=driver
[4] The timeout interval was guided by tests on an ATEN PE6108G where
    OFF->ON takes between 4-8 secs and ON->OFF less than 1 sec.
fixup! stbt power: Support ATEN network-controlled PDU's