module loader: Unload modules in reverse order of their start order

When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.

Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.

While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.

1. The linked list of modules has been replaced with a doubly linked list. This
   allows traversal of the module list to occur backwards. The module shutdown
   routine now walks the global list backwards when it attempts to unload
   modules.
2. The alphabetic reorganization of the module list on startup has been
   removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
   the modules - now does the sorting alphabetically itself. It creates its own
   linked list and inserts the modules into it in alphabetic order. This allows
   for the intent of the previous code to be maintained.

This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.

Review: https://reviewboard.asterisk.org/r/3777/


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@419563 f38db490-d61c-443f-a65b-d21fe96a405b
Multiple revisions 419565-419566

........
  r419565 | mjordan | 2014-07-25 09:41:23 -0500 (Fri, 25 Jul 2014) | 21 lines
  
  ARI: report duration values in LiveRecording objects
  
  This patch adds three new fields to the LiveRecording model:
   - total_duration: the total length of the live recording
   - talking_duration: optional. The duration of talking energy that was
     detected while the recording was made.
   - silence_duration: optional. The duration of silence that was detected while
     the recording was made.
  
  These values are reported in the RecordingFinished ARI event.
  
  When a DSP is enabled on the channel during the recording - which occurs when
  the recording is created with max_silence_seconds (indicating that the user
  actually cares about how much silence is in the file), we will report the
  talking_duration and silence_duration in addition to the total_duration.
  
  Review: https://reviewboard.asterisk.org/r/3770/
  
  ASTERISK-24037 #close
  Reported by: Samuel Galarneau
........
  r419566 | mjordan | 2014-07-25 09:46:15 -0500 (Fri, 25 Jul 2014) | 1 line
  
  Update CHANGES for r419565
........

Merged revisions 419565-419566 from http://svn.asterisk.org/svn/asterisk/branches/12


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