Fix remote connection to targets that don't support the QNonStop packet.

... and others.  The recent patch that fixed several "set remote
foo-packet on/off" commands introduced a regression, observable when
connecting GDB to QEMU.  For instance:

        (gdb) set debug remote 1
        (gdb) tar rem :4444
        Remote debugging using :4444
        Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
        Packet received: PacketSize=1000;qXfer:features:read+
        Packet qSupported (supported-packets) is supported
        Sending packet: $Hgp0.0#ad...Ack
        Packet received: OK
        Sending packet: $qXfer:features:read:target.xml:0,ffb#79...Ack
        Packet received: [...]
        Sending packet: $qXfer:features:read:arm-core.xml:0,ffb#08...Ack
        Packet received: [...]
 !!! -> Sending packet: $QNonStop:0#8c...Ack
        Packet received:
        Remote refused setting all-stop mode with:

The "QNonStop" feature is associated with the PACKET_QNonStop packet,
with a default of PACKET_DISABLE, so GDB should not be sending the
packet at all.

The patch that introduced the regression decoupled packet_config's
'detect' and 'support' fields, making the former (an auto_boolean)
purely the associated "set remote foo-packet" command's variable.  In
the example above, the packet config's 'supported' field does end up
correctly set to PACKET_DISABLE.  However, nothing is presently
initializing packet configs that don't actually have a command
associated.  Those configs's 'detect' field then ends up set to
AUTO_BOOLEAN_TRUE, simply because that happens to be 0.  This forces
GDB to assume the packet is supported, irrespective of what the target
claims it supports, just like if the user had done "set remote
foo-packet on" (this being the associated command, if there was one).

Ideally, all packet configs would have a command associated.  While
that isn't true, make sure all packet configs are initialized, even if
no command is associated, and add an assertion that prevents adding
more packets/features without an associated command.

Tested on x86_64 Fedora 17, against pristine gdbserver, and against a
gdbserver with the QNonStop packet/feature disabled with a local hack.

gdb/
2014-04-29  Pedro Alves  <palves@redhat.com>

	* remote.c (struct packet_config) <detect>: Extend comment.
	(add_packet_config_cmd): Don't set the config's detect or support
	fields here.
	(init_all_packet_configs): Also initialize the config's 'detect'
	field.
	(reset_all_packet_configs_support): New function.
	(remote_open_1): Call reset_all_packet_configs_support instead of
	init_all_packet_configs.
	(_initialize_remote): Initialize all packet configs.  Assert that
	all packets have an associated command, except a few known
	outliers.
or1k: Do not override section for non-TLS symbols.

Outgoing section for relocations was computed by setting a shared
pointer to which section should be used. For TLS this was overriden to
use .rela.got since they use GOT entries but since the pointer is per
section that whole section was relocated to .rela.got, even non-TLS
relocations.

* elf32-or1k.c: Fix a bug where non-TLS relocations would be forced
into .rela.got if it contained TLS relocations as well.