nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing

We observed on Windows 2012 that we were unable to unwind past
exception handlers. For instance, with any Ada program raising
an exception that does not get handled:

    % gnatmake -g a -bargs -shared
    % gdb a
    (gdb) start
    (gdb) catch exception unhandled
    Catchpoint 2: unhandled Ada exceptions
    (gdb) c
    Catchpoint 2, unhandled CONSTRAINT_ERROR at <__gnat_unhandled_exception> (
        e=0x645ff820 <constraint_error>) at s-excdeb.adb:53
    53      s-excdeb.adb: No such file or directory.

At this point, we can already see that something went wrong, since
the frame selected by the debugger corresponds to a runtime function
rather than the function in the user code that caused the exception
to be raised (in our case procedure A).

This is further confirmed by the fact that we are unable to unwind
all the way to procedure A:

    (gdb) bt
    #0  <__gnat_unhandled_exception> (e=0x645ff820 <constraint_error>)
        at s-excdeb.adb:53
    #1  0x000000006444e9a3 in <__gnat_notify_unhandled_exception> (excep=0x284d2
+0)
        at a-exextr.adb:144
    #2  0x00000000645f106a in __gnat_personality_imp ()
       from C:\[...]\libgnat-7.3.dll
    #3  0x000000006144d1b7 in _GCC_specific_handler (ms_exc=0x242fab0,
        this_frame=0x242fe60, ms_orig_context=0x242f5c0, ms_disp=0x242ef70,
        gcc_per=0x645f0960 <__gnat_personality_imp>)
        at ../../../src/libgcc/unwind-seh.c:289
    #4  0x00000000645f1211 in __gnat_personality_seh0 ()
       from C:\[...]\libgnat-7.3.dll
    #5  0x000007fad3879f4d in ?? ()
    Backtrace stopped: previous frame inner to this frame (corrupt stack?)

It turns out that the unwinder has been doing its job flawlessly
up until frame #5. The address in frame #5 is correct, but GDB
is not able to associate it with any symbol or unwind record.

And this is because this address is inside ntdll.dll, and when
we received the LOAD_DLL_DEBUG_EVENT for that DLL, the system
was not able to tell us the name of the library, thus causing us
to silently ignoring the event. Because GDB does not know about
ntdll.dll, it is unable to access the unwind information from it.
And because the function at that address does not use a frame
pointer, the unwinding becomes impossible.

This patch helps recovering ntdll.dll at the end of the "run/attach"
phase, simply by trying to locate that specific DLL again.

In terms of our medium to long term planning, it seems to me that
we should be able to simplify the code by ignoring LOAD_DLL_DEBUG_EVENT
during the startup phase, and modify windows_ensure_ntdll_loaded
to then detect and report all shared libraries after we've finished
inferior creation.  But for a change just before 7.7 branch creation,
I thought it was safest to just handle ntdll.dll specifically. This
is less intrusive, and ntdll is the only DLL affected by the problem
I know so far.

gdb/ChangeLog:

	* windows-nat.c (handle_load_dll): Add comments.
        (windows_ensure_ntdll_loaded): New function.
	(do_initial_windows_stuff): Use windows_ensure_ntdll_loaded.
        Add FIXME comment.
GDB/MI: Document support for -exec-run --start in -list-features

This adds "exec-run-start-option" in the output of the -list-features
commands, allowing front-ends to easily determine whether -exec-run
supports the --start option.

gdb/ChangeLog:

        * mi/mi-main.c (mi_cmd_list_features): add "exec-run-start-option".
        * NEWS: Expand the entry documenting the new -exec-run --start
        option to mention the corresponding new entry in the output of
        "-list-features".

gdb/doc/ChangeLog:

	* gdb.texinfo (GDB/MI Miscellaneous Commands): Document the new
	"exec-run-start-option" entry in the output of the "-list-features"
	command.

gdb/testsuite/ChangeLog:

        * gdb.mi/mi-start.exp: Add test verifying that -list-features
        contains "exec-run-start-option".
Set language for Ada minimal symbols.

This helps with the following issue: Given an Ada program defining
a global variable:

    package Pck is
       Watch : Integer := 1974;
    end Pck;

When printing the address of this variable, GDB also tries to print
the associated symbol name:

    (gdb) p watch'address
    $1 = (access integer) 0x6139d8 <pck__watch>
                                       ^^
                                       ||

The problem is that GDB prints the variable's linkage name, instead
of its natural name. This is because the language of the associated
minimal symbol never really gets set.

This patch adds handling for Ada symbols in symbol_find_demangled_name.
After this patch, we now get:

    (gdb) p watch'address
    $1 = (access integer) 0x6139d8 <pck.watch>
                                       ^
                                       |

gdb/ChangeLog:

        * symtab.c (symbol_find_demangled_name): Add handling of
        Ada symbols.

gdb/testsuite/ChangeLog:

        * gdb.ada/int_deref.exp: Add test verifying that we print
        the decoded symbol name when printing the address of Ada
        symbols.