This adds a config file format for the GPU offloading interface in !224.
With this, the app profile library will read config files in a couple directories to find the app profile data for the current process. The app profile library itself provides the same interface, so the format (or even existence) of the config files is opaque to the rest of libglvnd. And since this all gets called from libglvnd, it will work regardless of which window system or desktop environment (or lack thereof) you happen to be using.
It'll also work correctly with things like Steam, where just having the desktop environment set an environment variable would not work.
The format I've defined here is TOML-based. I picked that because it's easy to parse, easy to extend, and is human- or machine-editable. The array-of-tables syntax also makes defining a list of profiles pretty clean.
Each config file can define a list of profiles, and the parser will search until it finds one that matches the current process. The profile can then have a list of device ID's that get handed back to EGL/GLX/Vulkan. The device ID's are strings in the format of vendor_name/device_uuid, just like you'd pass with the environment variable.
Currently, the parser can match a profile based on the API name and based on the value in /proc/self/exe and /proc/self/comm. The match rules are structured so that we can add new ones without breaking compatibility, too. Off the top of my head, we'll probably want something that could be used with programs running through Wine or an interpreter.
In addition to using a specific device name, a profile can also use a symbolic alias. In that case, the same config files can define a device ID for that alias. The reason for the alias feature is so that users (or distros or drivers or whoever) can define a profile for an application with a generic category like "performance", without having to know what the specific hardware configuration is going to be. Then, a config file can define which device is the "performance" device using whatever policy you want. A user could define an alias manually, or you could have a program generate a config file at startup or in response to hotplug events.