This sets the name displayed by PulseAudio to Librespot - Instance Name if a name is given otherwise Librespot (the default name).
This also sets the correct "role" as per the docs:
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/ApplicationProperties/
PA_PROP_MEDIA_ROLE
"This is a property of the actual streamed data, not so much the application"
Roles are used for policies, things like automatically muting a music player when a call comes in and whatnot.
For bonus points this also sets PULSE_PROP_application.icon_name to audio-x-generic so that we get a nice icon in the PulseAudio settings by our name instead of a missing icon placeholder.
This saves up to 1-2% CPU useage on a PI 4 depending on how much normalisation is actually being done.
* We don't need to test against EPSILON. The factor will never be over 1.0 in basic normalisation mode.
* Don't check the normalisation mode EVERY sample.
* Do as little math as possible by simplfiying all equations as much as possible (while still retaining the textbook equations in comments).
* Misc cleanup
* Update GStreamer backend to 0.18
* Don't manually go through all intermediate states when shutting down the GStreamer backend; that happens automatically
* Don't initialize GStreamer twice
* Use less stringly-typed API for configuring the appsrc
* Create our own main context instead of stealing the default one; if the application somewhere else uses the default main context this would otherwise fail in interesting ways
* Create GStreamer pipeline more explicitly instead of going via strings for everything
* Add an audioresample element before the sink in case the sink doesn't support the sample rate
* Remove unnecessary `as_bytes()` call
* Use a GStreamer bus sync handler instead of spawning a new thread with a mainloop; it's only used for printing errors or when the end of the stream is reached, which can also be done as well when synchronously handling messages.
* Change `expect()` calls to proper error returns wherever possible in GStreamer backend
* Store asynchronously reported error in GStreamer backend and return them on next write
* Update MSRV to 1.56
When there's a value that corresponds to an argument name used in the same command line, the logging of the arguments gets confused and logs the matching argument, but without the leading dash:
```
% target/debug/librespot -n c --verbose -c /path/to/my/cache
[2022-02-07T22:32:25Z INFO librespot] librespot 0.3.1 55ced49 (Built on 2022-02-07, Build ID: qaEB8kEW, Profile: debug)
[2022-02-07T22:32:25Z TRACE librespot] Command line argument(s):
[2022-02-07T22:32:25Z TRACE librespot] -n "c"
[2022-02-07T22:32:25Z TRACE librespot] c "/path/to/my/cache"
[2022-02-07T22:32:25Z TRACE librespot] --verbose
[2022-02-07T22:32:25Z TRACE librespot] -c "/path/to/my/cache"
```
Here we're using the literal `c` as the device name, and the `-c` argument. Thus the `c /path/to/my/cache` is logged in addition to `-c /path...`.
After checking whether the key has a leading dash, this issue is gone:
```
% target/debug/librespot -n c --verbose -c /path/to/my/cache
[2022-02-07T22:32:41Z INFO librespot] librespot 0.3.1 55ced49 (Built on 2022-02-07, Build ID: qaEB8kEW, Profile: debug)
[2022-02-07T22:32:41Z TRACE librespot] Command line argument(s):
[2022-02-07T22:32:41Z TRACE librespot] -n "c"
[2022-02-07T22:32:41Z TRACE librespot] --verbose
[2022-02-07T22:32:41Z TRACE librespot] -c "/path/to/my/cache"
```
