Two decisions NetBSD needs for the drmkms update to really impact userland

[David Shao <davshao%gmail.com@localhost>]

There are two decisions NetBSD needs for the drmkms update to actually
be useful for userland.  Mesa's current requirements are quite modest for
Linux kernel compatibility -- I think only something like 3.9.

First, recall kern/51786
"mesa 13.0.2 libdrm 2.4.74 Radeon needs kernel support, new ioctl or sysctl".
What modern mesa actually needs is for some way for the kernel to communicate
to userland, libdrm in particular, PCI graphics card information.
There are at least
3 reasonable ways to do this, and a patch was provided in that bug report that
was basically a line-by-line copy of OpenBSD's approach at the time.  Sysctl,
ioctl, /dev/pci -- someone just pick one.  That is all it takes to update mesa
through 17.1 and compile-wise through 18.0 for NetBSD amd64.

By the way, there's something not being detected properly for mundane types
such as uint64_t for mesa 18.1 and 18.2 causing compiling to fail for me for
pkgsrc and amd64.

Second, there is the continuing problem of dlopen and init-exec.
(This is a problem
apparently all the BSDs at some point need to address.)  NetBSD for pkgsrc mesa
had a patch using an variable table_noop_array.  For now it is
possible to get more
recent mesa to compile by NOT building glesv1 and NOT building glesv2.