Stasis: address refcount races; implementation comments

Change r395954 reordered some stasis object destruction, which should
have been fine. Unfortunately, it caused some hard to reproduce issues
related to objects being accessed after they had been destroyed. The
patch in r396329 fixed the destruction order problem; this patch
addresses the underlying issue. A few other stasis-related fixes were
also added.

 * Add ref-bumps around areas where objects may get transitively
   destroyed. (For example, where we lock a topic, unref a subscription,
   which unrefs the topic, which explodes the topic when we try to
   unlock it.)

 * Wrote an extensive doxygen page about Stasis implementation,
   relationships between objects, lifecycles of objects, how the
   refcounting works, etc. Many other comments were added, corrected, or
   cleaned up.

 * Added an assert to the topic dtor to catch extra ref decrements.

 * Fixed type used after destruction errors for graceful shutdown in
   stasis_channels.c.

 * I added two unit tests in an attempt to catch destruction order
   issues. Since the underlying cause is a race condition, though, the
   tests rarely failed even when the code was wrong.

 * Fixed a leak in stasis_cache_pattern.c.

(closes issue ASTERISK-22243)
Review: https://reviewboard.asterisk.org/r/2746/


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@396842 f38db490-d61c-443f-a65b-d21fe96a405b
utils.h: Minor formatting tweaks.

git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@396849 f38db490-d61c-443f-a65b-d21fe96a405b
Fix utilities compilation/linking.

The horrid structure of the source in the utils directory strikes again.
Moved the _ast_mem_backtrace_buffer[] definition from the logical location
in utils.c to hashtab.c so the aelparse and conf2ael utilities can link.


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@396850 f38db490-d61c-443f-a65b-d21fe96a405b