Fix ARI warning in thread-thread.c::dec_thread_get_ada_task_ptid

This patch fixes the following ARI warning:

    gdb/dec-thread.c:695: regression: multi-line string: Multi-line string
    must have the newline escaped

I think the new-line was unintentional, so I simply removed it,
and then reformatted the string to fit within our 70-80 max characters-
per-line rule.

gdb/ChangeLog:

       * dec-thread.c (dec_thread_get_ada_task_ptid): Avoid unescaped
       new-line in debug string.  Remove trailing spaces.
Deprecate windows-specific dll-symbols command and aliases

The "dll-symbols" command, specific to native Windows platforms,
gives the impression that the symbols were not loaded, first
because it completes silently, and second because the "info shared"
output does not get updated after the command completes:

    (gdb) dll-symbols C:\WINDOWS\syswow64\rpcrt4.dll
    (gdb) info shared
    From        To          Syms Read   Shared Object Library
    [...]
    0x77e51000  0x77ee2554  No          C:\WINDOWS\system32\rpcrt4.dll

(we exected the "Syms Read" column to read "Yes").

As far as I can tell, the symbols actually do get loaded, but completely
independently from the solib framework, which explains the silent
loading and the fact that the "Syms Read" column does not get updated.
See windows-nat.c::safe_symbol_file_add_stub, which calls symbol_file_add
instead of calling solib_add.

But, aside from the fact that the "Syms Read" status does not get
updated, I also noticed that it does not take into account the DLL's
actual load address when loading its symbols. As a result, I believe
that we get it wrong if the DLL does not get loaded at the prefered
address.

Rather than trying to fix this command, there does not seem to be
a reason other than historical for having Windows-specific commands
which essentially re-implements the "sharedlibrary" command. The
command interface is slightly different (the latter takes a regexp
rather than a plain filename), but it should be just as easy to use
the "sharedlibrary" command, or its "share" alias, as usisng the
"dll-symbols" command. For instance:

    (gdb) share rpcrt4.dll
    Reading symbols from C:\WINDOWS\system32\rpcrt4.dll...(no debugging symbols found)...done.
    Loaded symbols for C:\WINDOWS\system32\rpcrt4.dll
    (gdb) info shared
    From        To          Syms Read   Shared Object Library
    [...]
    0x77e51000  0x77ee2554  Yes (*)     C:\WINDOWS\system32\rpcrt4.dll

This patch therefore deprecates the "dll-symbols" command, as well
as its two aliases "add-shared-symbol-files" and "assf", with a view
of deleting them as soon as the 7.8 branch gets cut.

gdb/ChangeLog:

	* windows-nat.c (_initialize_windows_nat): Deprecate the
	"dll-symbols" command.  Turn the "add-shared-symbol-files"
	and "assf" aliases into commands, and deprecate them as well.
	* NEWS: Add entry explaining that "dll-symbols" and its two
	aliases are now deprecated.

gdb/doc/ChangeLog:

        * gdb.texinfo (Files): Document "add-shared-symbol-files"
        and "assf" as being deprecated.
        (Cygwin Native): Likewise for "dll-symbols".
        (Non-debug DLL Symbols): Remove reference to "dll-symbols"
        as a way to force the loading of symbols from a DLL.
Ignore DLL load/unload events during inferior initialization.

This patch aims at simplifying DLL handling during the inferior
initialization (process creation during the "run", or during an
"attach"). Instead of processing each DLL load event, which is
sometimes incomplete, we ignore these events until the inferior
has completed its startup phase, and then just iterate over all
DLLs via EnumProcessModules.

gdb/ChangeLog:

        * windows-nat.c (get_windows_debug_event): Ignore
        LOAD_DLL_DEBUG_EVENT and UNLOAD_DLL_DEBUG_EVENT
        if windows_initialization_done == 0.
        (windows_add_all_dlls): Renames windows_ensure_ntdll_loaded.
        Adjust implementation to always load all DLLs.
        (do_initial_windows_stuff): Replace call to
        windows_ensure_ntdll_loaded by call to windows_add_all_dlls.
Windows: Rely purely on event info when handling DLL load event

When a DLL gets loaded an the debugger gets a debug event about it,
the currently implementation in handle_load_dll currently tries to
fetch the DLL's name by first iterating over all DLLs known to
the system.  It should be sufficient to rely on the name provided
with the event, however, especially in the situation we are now,
where we now know that we're past the statup phase for our inferior.

This patch therefore simplifies windows-nat.c::handle_load_dll to
only rely on the event's lpImageName.

It also updates the function's comment to document the assumption
regarding not being during the inferior's startup phase. And while
at it, it fixes the function documentation, which was probably
unintentionally inherited from another function (perhaps windows_wait).

gdb/ChangeLog:

	* windows-nat.c (handle_load_dll): Rewrite this function's
	introductory comment.  Remove code using get_module_name
	to get the DLL's name.
Simplify windows-nat.c::get_module_name

Now that get_module_name is no longer called for handling DLL events,
we can simplify it a bit, knowing that the only use is to get the
executable's filename.

While doing so, we adjusted the implementation a bit to avoid
references to DLLs, renamed it to make its more-targeted usage
more explicit, moved it right before the only function that uses it.
We also remove the use of hard-coded length for the buffers being
used.

gdb/ChangeLog:

	* windows-nat.c (get_module_name): Delete.
	(windows_get_exec_module_filename): New function, mostly
	inspired from get_module_name.
	(windows_pid_to_exec_file): Replace call to get_module_name
	by call to windows_get_exec_module_filename.