Move logging callback into an OpenAL extension

[MathiusD]

The aim here is to enable access to a logging callback through an OpenAL extension (here ALC_SOFT_logging_events).

Logging callback has already been implemented here: #862.

The only difference with the previously implemented callback is the following modifications:

The log level is now represented by an ALCenum
Two new parameters are added:

• A null terminated string containing the name of the entity issuing the log.
• The size of the previous parameter

This string, representing the emitter, can be null, if the implementation cannot provide an emitter section. The emitter represents the impacted section, aka the name of the extension, name of method, or name of specification from which the log comes.

[kcat]

I'm not keen on making this an extension since it's dealing with implementation details of what the library's doing, things which can change. The app isn't supposed to gleam any details from it, it's just a way to include OpenAL Soft's logging messages in the app's own log, to avoid the user having to mess with the ALSOFT_LOGLEVEL/ALSOFT_LOGFILE env var stuff.

There is instead the AL_EXT_debug API for the app to get OpenAL-related messages (primarily just API errors for now, with some portability warnings).

[MathiusD]

Okay, I understand (and to tell the truth, I hadn't explored AL_EXT_DEBUG enough ^^' and i'd like to use alsoft non extension exports (Without include alc/inprogrext.h because following contains many symbols for unreleased extension and ABI) so i have submitted current PR)

However, I'd like to take this opportunity to ask another question: Is it desirable to expose these implementation-dependent methods (i.e. all those in inprogrext.h that don't concern an extension or an ABI) in a public include? (For example, in include/SOFT/api.h) (An example of what I mean here : master...mathiusd:feature/move_non_standard_export_into_dedicated_header) (I ask because it allows anyone to manage includes more finely).

[kcat]

Functions that don't have AL_API or ALC_API aren't exported from the library, so a function declaration in a public header isn't too appropriate. I also prefer to limit the number of exported non-essential functions (non-standard, and what an app won't require to work).

Ideally I'd like a way to export a function so that it can be retrieved with dlsym/GetProcAddress, but not used directly to get at link-time. There doesn't seem to be a way to do that though, and putting it in a public header would make it easy to make the function required at run-time.

[MathiusD]

Okay, thanks a lot for the explanation!