s390/ap: use generic driver_override infrastructure

In the Linux kernel, the following vulnerability has been resolved:

s390/ap: use generic driver_override infrastructure

When the AP masks are updated via apmask_store() or aqmask_store(),

ap_bus_revise_bindings() is called after ap_attr_mutex has been

released.

This calls __ap_revise_reserved(), which accesses the driver_override

field without holding any lock, racing against a concurrent

driver_override_store() that may free the old string, resulting in a

potential UAF.

Fix this by using the driver-core driver_override infrastructure, which

protects all accesses with an internal spinlock.

Note that unlike most other buses, the AP bus does not check

driver_override in its match() callback; the override is checked in

ap_device_probe() and __ap_revise_reserved() instead.

Also note that we do not enable the driver_override feature of struct

bus_type, as AP - in contrast to most other buses - passes "" to

sysfs_emit() when the driver_override pointer is NULL. Thus, printing

"\n" instead of "(null)\n".

Additionally, AP has a custom counter that is modified in the

corresponding custom driver_override_store().