All existing stage planers(PlanStageGreedy, PlanStageProtected,
PlanStageHiSi) silently ignore if they couldn't allocate a drmplane
for a drmhwclayer and return success.

That doesn't go well with the assumptions from ValidateDisplay,
where if the atomic check succeeds we just assume that we could do
Device composition for a maximum of num_of_drm_planes layers. But,
since we silently dropped some drmhwclayer we never put those in the
atomic check and we won't put it in the final atomic commit, so we end
up with a wrong composition on the screen.

What this proposes is propagating the error, which will make
ValidateDisplay to fallback on client composition.

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>