Draft: Safer access to EDID data, for more control over "valid" data

With std::optional ambiguity is removed over whether EDID data is present at all, or whether any provided EDID data is not valid. Functionally, the difference between "no EDID" and "invalid EDID" is quite academic - but now consumers are enabled to make their own decisions in either case.

The main benefit of this change is to raise awareness of EDID data being amiss one way or the other, and hence alerting the developer towards correctly using the API: As a result of the required adjustments to check for has_value() a number of locations could be identified (and adjusted) where the handling of the "EDID data amiss" scenario was suboptimally expressed in code, or even hiding a defect (in output state store lookup)

In particular, OutputConfigurationStore::findOutput contains intricate change with impact on functional behaviour: a) don't access empty/invalid EDID data; b) don't persist empty EDID data; and c) a refactoring of the lookup in general to make EDID / MST path / connector name access clearer - in the hope to not have introduced unwanted behavioural change.

For item c) in particular, computing MST path uniqueness and then identifying the item in the configuration state store now match

As a drive-by fix, the last commit contains code to check whether EDID parsing was successful (function is present since the first ever git tag of libdisplay-info).