gdb: make solib-svr4 not use so_list internally

gdb: make solib-svr4 not use so_list internally

A subsequent patch makes use of non-trivial types in struct so_list.
This trips on the fact that svr4_copy_library_list uses memcpy to copy
so_list objects:

      so_list *newobj = new so_list;
      memcpy (newobj, src, sizeof (struct so_list));

solib-svr4 maintains lists of so_list objects in its own internal data
structures.  When requested to return a list of so_list objects (through
target_so_ops::current_sos), it duplicates the internal so_list lists,
using memcpy.  When changing so_list to make it non-trivial, we would
need to replace this use of memcpy somehow.  That would mean making
so_list copyable, with all the complexity that entails, just to satisfy
this internal usage of solib-svr4 (and solib-rocm, which does the same).

Change solib-svr4 to use its own data type for its internal lists.  The
use of so_list is a bit overkill anyway, as most fields of so_list are
irrelevant for this internal use.

 - Introduce svr4_so, which contains just an std::string for the name
   and a unique_ptr for the lm_info.
 - Change the internal so_list lists to be std::vector<svr4_so>.  Vector
   seems like a good choice for this, we don't need to insert/remove
   elements in the middle of these internal lists.
 - Remove svr4_free_library_list, free_solib_lists and ~svr4_info, as
   everything is managed automatically now.
 - Replace svr4_copy_library_list (which duplicated internal lists in
   order to return them to the core) with so_list_from_svr4_sos, which
   creates an so_list list from a vector of svr4_so.
 - Generalize svr4_same a bit, because find_debug_base_for_solib now
   needs to compare an so_list and an svr4_so to see if they are the
   same.

Change-Id: I6012e48e07aace2a8172b74b389f9547ce777877
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>