gdb: Don't store a thread-id for floating varobj

gdb: Don't store a thread-id for floating varobj

When creating a varobj with -var-create a user can create either fixed
varobj, or floating varobj.

A fixed varobj will always be evaluated within the thread/frame/block in
which the varobj was created, if that thread/frame/block is no longer
available then the varobj is considered out of scope.

A floating varobj will always be evaluated within the current
thread/frame/block.

Despite never using them GDB was storing the thread/frame/block into a
floating varobj, and the thread-id would then be displayed when GDB
reported on the state of the varobj, this could confuse a user into
thinking that the thread-id was relevant.

This commit prevents GDB storing the thread/frame/block onto floating
varobj, and updates the few tests where this impacts the results.

gdb/ChangeLog:

	* varobj.c (varobj_create): Don't set valid_block when creating a
	floating varobj.

gdb/testsuite/ChangeLog:

	* gdb.python/py-mi.exp: Don't expect a thread-id for floating
	varobj.
	* gdb.mi/mi-var-create-rtti.exp: Likewise.