control: Add Device::crtc_get/queue_sequence() IOCTLs and event

[MarijnS95]

These two IOCTLs are for querying the most recent sequence number (and its "first pixel out" timestamp) as well as scheduling (queueing) an event when a future sequence number (absolute or relative) is hit, equally containing the "first pixel out" timestamp for that sequence.

As with wait_vblank(), crtc_queue_sequence() also returns the absolute sequence number that the event ended up latching on. This is useful when specifying a relative index as well as when the driver max()es an absolute target to the most recently triggered sequence. This request will still result in an event even when that sequence number has already been hit, but doesn't allow you to queue older frames.

To figure out

• Do the new IOCTLs belong to the mode, or outside of it (i.e. in src/lib.rs or src/control/mod.rs)?
• Since events can be fired for wait_vblank() which is outside of control, should receive_events() be moved to the (or is the optional wait_vblank(EVENT, ...) flag a feature of a modesetting device)?
• Where to find if Locks DRM mutex should be true or false?

"Unrelated" TODOs

Note that this PR is much bigger than just these two IOCTLs, as I started cleaning through and playing with the code. There are a bunch of TODOs remaining in the code, mostly questions for the maintainers to decide how to proceed. And a lot of unrelated changes to be split out.

• Expose user_data field on page_flip() just like wait_vblank(), since the crtc_id field will always be set from kernel 4.12 onwards?
• Remove getter functions from PODs and make their fields pub? I.e. ResourceHandles already has pub fields and doesn't need trivial getters, WaitVblankReply could use the same.
• Merge PageFlipTarget and WaitVblankTarget?
• Use more doc(alias) to make it easier to relate low-level DRM code to the higher-level wrappers here.
• Use more intradoc links to link i.e. events, their register functions, and flags together. Same for Capabilities when they affect a specific function/struct/field/flag.
• Make the Events iterator (basically a buffered reader) consume events from the fd indefinitely? Or at the very least document that it reads 1024 bytes of data (rounded down to a whole number of events that would fit), leaving them unaware of whether more events are available unless they keep calling read_events() in a loop till it returns an empty iterator?

[Drakulix]

Do the new IOCTLs belong to the mode, or outside of it (i.e. in src/lib.rs or src/control/mod.rs)?

I think the differentiating factor between the two modules was supposed to be what you can do on any drm-node vs a control-node. That obviously never really materialized as control-nodes never took off in favor of just using the primary node. The closest match today would be to figure out, which ioctls needs DRM_MASTER/authentification (these would belong into control) and which don't. I am not sure if we already violate that with wait_vblank.

Where to find if Locks DRM mutex should be true or false?

That is something @Slabity pulled from the kernel code at some point as far as I am aware.

Expose user_data field on page_flip() just like wait_vblank(), since the crtc_id field will always be set from kernel 4.12 onwards?

We might want to start documenting a minimum supported kernel version at some point...

[the rest]

Sound like good ideas for general cleanup.