Add Target.ensure_kconfig()

[douglas-raillard-arm]

Code sometimes need to check if some kernel config options is enabled. For a lot of them, checking they are =y is actually stricter than necessary, but allowing =m means the check can succeed without the feature being actually available if the corresponding module was not loaded.

To alleviate that, we could have a Target.ensure_kconfig() method that:

• Checks if the option =y and if so returns
• if =n or config does not exist at all, raises an exception
• if =m, tried to lsmod/modprobe the corresponding module and raises if that fails.

Unfortunately, there is no generic way of knowing the module name associated with a given kconfig, so the mapping has hard coded. However, we can have a maintenance script that finds a mapping for a given kernel source tree by looking for obj-$(CONFIG_FOO) += the module.o anothermodule.o and merge the result with the existing mapping in devlib.

[douglas-raillard-arm]

Given the behavior of current Android GKI kernels, we cannot rely on =N meaning the feature is not available in a module, as the module may still be available (/proc/config.gz can lie in this way in Android apparently due to the way GKI build system works as reported by @patrik-arm). Therefore, the behavior we want is:

• Checks if the option =y and if so returns positively
• Otherwise, try to lsmod/modprobe the corresponding module and raises if that fails or if we don't know what module to load.

If the mapping config<->module name is not know for the feature, the function should raise an exception. It might be a good idea to allow the user to pass an expected module name so they can work around an incomplete mapping provided by devlib.

Since this is definitely a bug in Android, maybe we should check for the target type and use the sane behavior (=N means it's not available) on non-android targets, but that may mean some code working on mainline kernel would break on android targets, whereas having a single path working for the buggy case will ensure user code works in both cases.