Fix router not loading on Creative's hardware OpenAL

According to the programming guide and the specification, those functions may be used by extensions. However, Creative's hardware OpenAL chose to not implement stub functions for those that they do not use. Currently they use only alBufferi for X-RAM related functions.

Other implementations, such as OpenAL Soft and wrap_oal implement stub functions for those methods therefore they work.

This commit turns those functions optional, just like they were in the old FOSS router. Consumers of the router will receive a nullptr as expected for not implemented methods if they load them using alGetProcAddress, which I believe is the correct way to do so. That is, the context must be current before loading al* functions.

If the context needs to be set before you can load the al* functions, it may make more sense to load them in InitCtxFuncs in alc.cpp, which is called the first time a context for a driver/iface is made current. alGetProcAddress itself would need to be loaded with GetProcAddress (or maybe with alcGetProcAddress?), but all the other al* functions can then be retrieved with alGetProcAddress with the context set as necessary.

My comment about alGetProcAddress is more addressed to any application calling the router, inside the router I don't really have an opinion on where to load those methods. AddModule feels fine as only real implementations are being loaded, but your proposal of moving everything to InitCtxFuncs is quite interesting as it guarantees that the correct functions are loaded. However, I think there would have to be stub implementations here to not cause problems on applications that call those methods before setting a context.

So, back to what I wrote before, an application must use alGetProcAddress to fetch any other al* method after setting the context as I think this is the only way the router can know which driver is to be used, but we know most applications just GetProcAddress away everything.

With that said, this talk just made me find a bug in my implementation. If the application used GetProcAddress instead of alGetProcAddress to get the addresses of everything, the router will return a wrapped function that will cause a nullptr dereference exception if those methods are called: https://github.com/kcat/openal-soft/blob/b2ab8841d2d37296db317a1174392ed041faed97/router/al.cpp#L16

I think I should stub those calls here instead of just not setting them: https://github.com/kcat/openal-soft/blob/6fd3c77be9ad321787d63b8e2e85565371b42b34/router/router.cpp#L216 Any opinion on that? I will do that tomorrow as it is late here already.

Any opinion on that? I will do that tomorrow as it is late here already.

Putting in default stubs makes sense, although I'm not sure how to do it in a safe/generic way since different functions have different argument and return types. Writing a different stub by hand for each would be some work.