Modernize dumbbuffer

[Drakulix]

Hey Slabity,

to speed up #25 a bit, I tried to fix the buffer and dumbbuffer apis and would like to have some feedback.

1. I had to move the ResourceHandle type into the root of the crate, because I think the GEM buffer handle needs this type as well.
2. The added functions are all in the ControlDevice, because they require DRM_AUTH or DRM_MASTER (except for close_buffer, which is even allowed for RenderNodes).
3. I have not added the flink call, as it does not exist in drm-ffi yet, do you want to support that?

Some additional questions, that showed themselves, when implementing this:

4. nix does not seem to have a no_std-variant, but you already use it in drm-ffi, so I went with it. Is this an oversight? Because then we could just go with std. To fix this we could just use libc instead.
5. Do you have a plan to move to stable? It seems str_internals is not going to be stablized any time soon, while nll is already available.

[Drakulix]

Looking at drmModeAddFb2 the current Buffer-trait might not be optimal and is likely the reason you started the PlanarBuffer-trait @Slabity, right?

Should PlanarBuffer be also implemented for every struct implementing Buffer? Technically every "normal" buffer is a PlanarBuffer with a single plane, right?

[Drakulix]

Since a lot of PRs started to require the buffer trait, I have now split of #38.
This now only adds the dumbbuffer-related functions.
Like this open discussion points regarding this PR, do not block anything else anymore.

Open points remaining:

• nix does not seem to have a no_std-variant, but you already use it in drm-ffi, so I went with it. Is this an oversight? Because then we could just go with std. To fix this we could just use libc instead.
• Do you have a plan to move to stable? It seems str_internals is not going to be stablized any time soon, while nll is already available.

[Slabity]

These changes have been pulled from another PR, so closing this one.

To address your questions:

nix does not seem to have a no_std-variant, but you already use it in drm-ffi, so I went with it. Is this an oversight? Because then we could just go with std. To fix this we could just use libc instead.

That's a good question. I'm not sure a no_std-variant would be useful, as that typically means your crate doesn't require features from the operating system. Doesn't really make sense for a crate that specifically exposes an OS subsystem.

Do you have a plan to move to stable? It seems str_internals is not going to be stablized any time soon, while nll is already available.

I don't plan on doing that until at least after the functionality for the control module is done. But it will happen eventually.

[Slabity]

Nevermind - I jumped the gun and realized that the actual dumbbuffer.rs changes were not pulled in.

[Drakulix]

These changes have been pulled from another PR, so closing this one.

Many of my PR did depend on the buffer PR, but contain additional commits. (like this one.)
Dumb-buffer support is likely not already merged, is it? I can rebase those, now that #38 is done.