Statement of aims
~~~~~~~~~~~~~~~~~
* Resiliance against corrupt or inaccurate EDID data from the monitor
  => some default display, and ability to override EDID data with 'known good' library copy
     in a similar manner to Windows overriding the EDID from an INF file as described here
     https://msdn.microsoft.com/en-us/library/windows/hardware/jj133967(v=vs.85).aspx
  => allow loading of disc based EDID on platforms that don't support it (eg. Risc PC)
* Simple user interface
  => user unlikely to care where the monitor settings came from, but they must work at least
     as well as the previous MDF system
  => checkbox or menu entry in !Configure plugin 
* Fallback to MonitorType=Auto behaviour if EDID unavailable
  => avoids problem when softload sets up to use EDID but underlying ROM OS doesn't support it
  => R-power-on/Delete-power-on/Keypad-dot-power-on revert to Auto as currently
* Advanced diagnostics for support staff
  => "many to 1" problem, so most of the complexity should reside on the support staff's desk,
     the remote system where the problem lies can be relatively simple
  => PC tools used to offline analyse EDID dumps (or, enhanced !MakeModes application)
  => means to capture EDID dump (utility, star command, BASIC, or similar)
* Discless boot
  => ability to select EDID without a boot sequence having run
  => ensure that the initial mode (prior to !Boot running) is feasible by vetting modes with the
     graphics driver
  => fallback to kernel's numbered modes if EDID is corrupt or inaccurate
* Hotplug and multi head
  => not currently supported, but design should not preclude their introduction in future, for
     example by setting the CMHG keyword matcher to let through some extra args but ignore
     them today