feat: a bmc driver that takes the best of Redfish and IPMI (0.4.0)

bmc (napalm_redfish.bmc:BmcDriver) reads a BMC over Redfish where it
answers. A BMC that refuses Redfish (no license) is read and switched over
IPMI. A getter that fails over Redfish is asked over IPMI where IPMI has it;
IPMI is opened only then. Power control goes over Redfish when it answers,
and a refusal is final. The BMC is reset over Redfish only. Same account
for both; ipmi_port in optional_args.

Discovery suggests bmc for a BMC it finds: the fingerprint rules moved from
RedfishDriver to BmcDriver.

README.md

@@ -36,6 +36,13 @@ not depend on it. Finding IPMI over LAN enabled is itself worth reporting, see
 |---|---|---|
 | `redfish` | HTTPS, Redfish REST (session token or basic auth) | Read, plus power control and BMC reset |
 | `ipmi` | IPMI 2.0 over LAN (UDP 623) via `pyghmi` | Read, plus power control (no graceful restart, no power cycle); no BMC reset |
+| `bmc` | Redfish first, IPMI where Redfish does not answer | Everything `redfish` does; a BMC that refuses Redfish (no license) is read and switched over IPMI, and a getter that fails over Redfish is asked over IPMI |
+
+`bmc` is the one to choose when unsure: it follows the BMC's license as it changes. A
+Supermicro X10 without a license is read over IPMI, with SFT-OOB-LIC over Redfish (which then
+reads more than IPMI: CPUs, DIMMs, NICs, power draw, the BIOS version, the SMBIOS UUID), and
+with DCMS also its drives and firmware inventory. `optional_args`: those of `redfish`, plus
+`ipmi_port` (623).
 
 Vendor quirks (Supermicro, Dell, HPE, Lenovo) live in one module per vendor, selected from
 the service root's `Vendor`/`Oem` data and `Manager.Model`. No separate entry point per