kallsyms: add /proc/kallmodsyms

kallsyms: add /proc/kallmodsyms

This procfile (controlled by CONFIG_KALLSYMS), introduces a new
/proc/kallmodsyms whose contents are the same as /proc/kallsyms, except that the
module name is provided even for built-in modules, as long as they could
potentially have been built as separate kernel modules.  DTrace will use it in
future to allow users to use the same module names in their D scripts regardless
of whether the modules are built-in or not in the kernel they happen to be
running.

This is done by scanning the object files named in the builtin.modules file
using libelf, extracting their function symbols, pruning out any symbols which
appear in more than one builtin module (since these are probably out-of-line
copies of inline functions in common kernel header files), then emitting the
names of all the modules in a new kallsyms_modules symbol and pointing at the
appropriate modules in a kallsyms_symbol_modules symbol which maps 1:1 to the
contents of kallsyms_addresses (thus, one kallsyms_symbol entry per kernel
symbol in /proc/kallsyms).  Always-built-in functions have a corresponding
kallsyms_symbol_modules index of zero.

This is not terribly space-efficient: the kallsyms_symbol_modules symbol is
quite large (~250K, mostly zeroes, four bytes per kernel symbol), but reducing
this requires some other way to signal that a symbol is not present in a module.
It is much smaller than even the compressed representation of the symbol names.

Possible future enhancements, low priority:
 - use a home-cooked hashtable rather than glib (pointless unless dwarf2ctf is
   similarly rejigged)
 - use nm rather than elfutils (liable to be quite a lot slower)
 - find a more robust way of detecting inlined functions, not fooled by
   out-of-line copies of inlined functions which happen to be used by
   only one module
 - shrink the kernel symbol space consumption, perhaps by using shorts rather
   than longs for the module offsets (65536Kb of module names should be enough
   for anybody)

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>