While the vast majority of drivers have support for hardware emulated
vblanks, there does exist hardware without such support - or where it's not
yet known how to take advantage of hardware vblank support. As a result,
vblank support for drivers in DRM is optional. Thus, our rust bindings for
this should also be optional.

In order to accomplish this, we introduce the VblankSupport trait which can
be implemented on DriverCrtc by drivers which support vblanks. This works
in the same way as the main Kms trait - drivers which don't support
hardware vblanks can simply pass PhantomData<Self> to the associated type
on DriverCrtc. If a driver chooses to implement VblankSupport, VblankImpl
will be implemented by DRM automatically - and can be passed to the
VblankImpl associated type on DriverCrtc.

Additionally, we gate methods which only apply to vblank-supporting drivers
by introducing a VblankDriverCrtc trait that is automatically implemented
by DRM for CRTC drivers implementing VblankSupport. This works basically in
the same way as Kms and KmsDriver, but for CRTCs.

One thing to keep in mind: this trait is implemented on the CRTC as opposed
to the KMS driver due to the possibility that a driver may have multiple
different types of CRTCs. As a result, it's not impossible that there could
potentially be differences in each type's vblank hardware implementation.
In theory this could lead to a driver mistakenly only implementing
VblankSupport for some CRTCs and not others, which isn't really defined
behavior in DRM. Thus, in one of our prior commits we taught DRM to check
for this at runtime and fail driver registration if this ends up being the
case.

Signed-off-by: Lyude Paul <lyude@redhat.com>