Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.

Specifically, it does the following:

* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
  remove passing the version in with the macro. Other facilities
  than 'core show file version' make use of the file names, such as
  setting a debug level only on a specific file. As such, the act of
  registering source files with the Asterisk core still has use. The
  macro rename now reflects the new macro purpose.

* main/asterisk:
  - Refactor the file_version structure to reflect that it no longer
    tracks a version field.
  - Remove the "core show file version" CLI command. Without the file
    version, it is no longer useful.
  - Remove the ast_file_version_find function. The file version is no
    longer tracked.
  - Rename ast_register_file_version/ast_unregister_file_version to
    ast_register_file/ast_unregister_file, respectively.

* main/manager: Remove value from the Version key of the ModuleCheck
  Action. The actual key itself has not been removed, as doing so would
  absolutely constitute a backwards incompatible change. However, since
  the file version is no longer tracked, there is no need to attempt to
  include it in the Version key.

* UPGRADE: Add notes for:
  - Modification to the ModuleCheck AMI Action
  - Removal of the "core show file version" CLI command

Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e

Greenlight in #asterisk brought up that he was receiving an error message "Could
not create persistent member string, out of space" when running app_queue in
Asterisk 10.  dump_queue_members() made an assumption that 8K would be enough to
store the generated string, but with queues that have large member lists this is
not always the case.  This patch removes the limitation and uses ast_str instead
of a fixed sized buffer.

The complicating factor comes from the fact that ast_db_get requires a buffer
and buffer size argument, which doesn't let us pull back more than what we pass
in, so I introduced a new ast_db_get_allocated() which returns an ast_strdup()'d
copy of the value from astdb.

As an aside, I did some testing on the maximum size of data that we can store in
the BDB library we distribute and was able to store a 10MB string and retrieve
it with no problems, so I feel this is a safe patch.

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

Merged revisions 374108 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 374135 from http://svn.asterisk.org/svn/asterisk/branches/10
........

Merged revisions 374150 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374151 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/10

................
  r338552 | qwell | 2011-09-29 15:54:55 -0500 (Thu, 29 Sep 2011) | 9 lines
  
  Merged revisions 338551 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.8
  
  ........
    r338551 | qwell | 2011-09-29 15:54:13 -0500 (Thu, 29 Sep 2011) | 1 line
    
    Test modules have a support level of core.
  ........
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@338553 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/10

................
  r338228 | qwell | 2011-09-28 15:54:35 -0500 (Wed, 28 Sep 2011) | 9 lines
  
  Merged revisions 338227 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.8
  
  ........
    r338227 | qwell | 2011-09-28 15:52:47 -0500 (Wed, 28 Sep 2011) | 1 line
    
    Add support levels to non-module sections of menuselect (cflags, utils, etc).
  ........
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@338229 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/10

................
  r332177 | pabelanger | 2011-08-16 16:11:49 -0400 (Tue, 16 Aug 2011) | 11 lines
  
  Merged revisions 332176 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.8
  
  ........
    r332176 | pabelanger | 2011-08-16 16:10:13 -0400 (Tue, 16 Aug 2011) | 4 lines
    
    Flag test modules as 'core'
    
    Review: https://reviewboard.asterisk.org/r/1369/
  ........
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@332178 65c4cc65-6c06-0410-ace0-fbb531ad65f3

There were some bugs in the very ancient version of Berkeley DB that Asterisk
used. Instead of spending the time tracking down the bugs in the Berkeley code
we move to the much better documented SQLite 3.

Conversion of the old astdb happens at runtime by running the included
astdb2sqlite3 utility. The ast_db API with SQLite 3 backend should behave
identically to the old Berkeley backend, but in the future we could offer a
much more robust interface.

We do not include the SQLite 3 library in the source tree, but instead rely
upon the distribution-provided libraries. SQLite is so ubiquitous that this
should not place undue burden on administrators.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@326589 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r323866 | twilson | 2011-06-15 15:03:58 -0500 (Wed, 15 Jun 2011) | 2 lines
  
  Remove now-useless cast of ARRAY_LEN
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@323867 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r323859 | twilson | 2011-06-15 14:45:20 -0500 (Wed, 15 Jun 2011) | 2 lines
  
  Fix more ARRAY_LEN format string issues
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@323860 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r323672 | twilson | 2011-06-15 10:09:51 -0700 (Wed, 15 Jun 2011) | 5 lines
  
  Cast ARRAY_LEN to size_t for ast_logging
  
  32-bit and 64-bit machines return different types for ARRAY_LEN(), so cast
  it before using in a format string.
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@323673 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r322923 | twilson | 2011-06-09 19:33:23 -0700 (Thu, 09 Jun 2011) | 2 lines
  
  Add some astdb unit tests
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@322940 65c4cc65-6c06-0410-ace0-fbb531ad65f3