hal: Update the last uspace drivers to getter/setter

[BsAtHome]

These are the last drivers (except hostmot2) that are compiled in uspace. The rest is rtai/kernel only afaict,which will come later.

Both hal_bb_gpio.c and hal_evoreg.c drivers are straight forward and not too big a change.
Apart from that, I think that the hard-coded number in the hal_evoreg.c pin-array sizes are off. The comments don't match the numbers and the implementation does neither. Not going to touch this can of worms. Also, there are several kernel-types still in the code. No sure anyone has tried this driver for some time.

The gm.h file has the hardware memory layout structure. All its members are volatile because this is a PCI MMIO. The old hal types cannot be (ab)used anymore, so the normal equivalent is used.
The hal_gm.c driver is a bit special because it abuses hal memory and pin target memory. It originally pointed to local parameters, but these do not work like that anymore. However, an overlay union was created to support taking the address of the target and pretend it to be a new hal type (it is all in HAL memory anyway). This is very ugly and non-portable, but it is the quickest way to fix the problem at hand. Otherwise the driver would need considerable work to be fixed. This hack is used in cardMgr_t and stepgen_t. Furthermore, it is a big driver with a some inefficient code. I really hope we can find anyone who can test this. The driver is "only" 14 years old with the last update 10 years ago...

The hal_parport.c driver uses parameters but does not always allocate them. It depends on the mode of the port. It has been verified that the allocations match the run-time conditions and there should be no crash.

The hal_ppmc.c driver is big and inefficient at times. Fixing that was harder than to let it be. At least it didn't get worse.

[grandixximo]

Builds clean; hal_parport loads and runs with the new API, the other drivers fail gracefully without hardware. The hal_gm fake-target hack is safe: disable stays 0 forever and the handles are read-only.

One finding inline in hal_evoreg.c: mask <<= 1 sits inside the if braces, so FALSE pins don't advance the mask and output bits collapse (pins {1,3} write 0x0003 instead of 0x000a). In master this was hidden by the always-true pointer test. Easy fix while these lines are being touched anyway.