Add more UDP branch hints

This should have been done in 53525a8c earlier but was overlooked
let libtool --silent follow automake silent-rules
Make the libgdnsd "prcu" interfaces public for plugins

*) 3rd party plugins can now use the gdnsd_prcu_* interfaces
defined in <gdnsd/prcu.h> to take advantage of the resolver
threads' existing urcu critical-section stuff in a similar manner
to how the core plugin_geoip does geoip/nets data reloads.

*) It's up to the plugin to define _LGPL_SOURCE to get some
additional minor performance benefits if the plugin source has an
LGPL-compatible license.

*) Whether the daemon was built with urcu support (as opposed to
pthread fallback) affects binary compatibility for plugins.  This
is exposed through a built and installed header for the plugin and
the existing simplistic runtime API versioning.  If the plugin is
built against headers that are built the same way as the installed
daemon, things will just work.

*) In the cases where the two are mismatched at runtime (for
example, by building and installing gdnsd without urcu support,
building a plugin against those installed headers, and then
rebuilding and reinstalling the main package *with* urcu support
but not rebuilding the plugin, or vice-versa), there are various
scenarios:

1) gdnsd has urcu, plugin doesn't: the plugin will load fine from
the dlopen() perspective, but it will fail the API versioning check
due to mismatched binary compatibility flags, causing a fatal
error message that mentions recompiling the plugin.

2) plugin has urcu, gdnsd doesn't: depending on lots of possible
factors (e.g. whether the plugin uses explicit prcu interfaces at
all, whether the author directly linked the plugin with
liburcu-qsbr for other reasons, possible user-level interference
via LD_PRELOAD, etc) the plugin may fail dlopen() for lack of a
necessary symbol from liburcu-qsbr, or it may succeed at dlopen()
and then fail the binary compatibility check as in (1) above.  In
either case, the error message will mention that it could be a
binary compatibility issue that can be addressed by recompiling.

Regardless, in all such scenarios, it should not be possible for
the code to continue running with the mismatch and cause later
errors that manifest as crashes or thread data sync issues, as
might otherwise be the case.