Use atomic_fetch_add from C11's stdatomic if available or fallback to
GCC's __atomic functions.

Remove atomic_add because is can trivially be implemented by calling
exchange_and_add instead.

ifdef is useless, since the value is always defined (either to 1 or 0) in config.h.

Fix inspired by

  https://svnweb.freebsd.org/ports/head/audio/jack/files/patch-drivers_dummy_dummy__driver.c?view=markup

Also simplified #if condition in libjack/time.c - it's easier to read a positive than a negated
condition.

Sets memory for valgrind even if USE_CAPABILITIES is not defined.

Uses static local variable like how jack_user_dir does. jack_get_tmpdir()
replaces jack_tmpdir for the most part except in jackd -l where it would
cause an infinite loop, and instead DEFAULT_TMP_DIR is used, which is
what it would happen anyway. Also in jack_user_dir the default value is
used if jack_user_dir returns NULL from some error, but an error message
is printed with jack_error(), this is the same as the old behavior, but
I am not sure this is quite what should happen. Still, the exact same
behavior as before is acheived except without the use of the jack_tmpdir
global and the memory issues caused by calling jack_get_tmpdir().

* Fix usage of `AC_INIT`.
* Extract JACK version numbers from `AC_INIT` version number.
* Newer versions of automake insists on the `subdir-objects` option
  when using C files from outside the current directory.
* Need to use generate `noinst_LTLIBRARIES` rather than just adding
  and out-of-dir C file to the `*_SOURCES`.

The "client" argument being passed to jack_set_property() is
jack_client_internal_t*, not jack_client_t* as expected, which leads
to a crash. Using client->private_client (which is a jack_client_t*)
causes deadlock because do_request() is called recursively.

The goal here is good, but it can't be accomplished in this way.

This reverts commit 439e47da1a.

This allows clients to deterministically show ports in the correct order
when there are more than 9 ports (where the lack of leading zeros breaks
sorting by name).

Issue
-----
JackPropertyChangeCallback returns a carbage key when removing all keys of
a given uuid, e.g. triggered by 'jack_remove_properties(...)'.

Expected
--------
JackPropertyChangeCallback should return a (NULL) key when removing all
keys of a given uuid.

Culprit
-------
'malloc' is called with key_size==0, which MAY NOT return a (NULL) pointer.

Fix
---
Do not call 'malloc' for key_size==0.

allow autostart of jackd on OSX where device-names can
contain spaces.

allow autostart of jackd on OSX where device-names can
contain spaces.

- jack_remove_properties and jack_get_properties both search the metadata database for matching UUID string.
- However, they both fail at finding any matching UUIDs ever.
- The UUID string in the database are correctly created on a previously cleared buffer (e.g. memset to 0).
- The temporaty UUID string in the search routines however are not created on a cleared buffer, the end of the buffer thus may contain anything.
- As in the matching routine the complete UUID strings are compared (with size JACK_UUID_STRING_SIZE), there will never be a matching air, even if their valid part do match.

This cannot be implemented at present because jack_port_set_name() does not take
a jack_client_t* as an argument, and thus no msg can be sent to the server
regarding the name change. Jack2 accomplishes this by walking its static array
of clients to find one that is in use and sends the msg using that one. This
is not possible in Jack1 because we do not use static arrays of clients (or
ports).