gdb/python: restrict the names accepted by gdb.register_window_type

gdb/python: restrict the names accepted by gdb.register_window_type

I noticed that, from Python, I could register a new TUI window that
had whitespace in its name, like this:

  gdb.register_window_type('my window', MyWindowType)

however, it is not possible to then use this window in a new TUI
layout, e.g.:

  (gdb) tui new-layout foo my window 1 cmd 1
  Unknown window "my"
  (gdb) tui new-layout foo "my window" 1 cmd 1
  Unknown window ""my"
  (gdb) tui new-layout foo my\ window 1 cmd 1
  Unknown window "my\"

GDB clearly uses the whitespace to split the incoming command line.

I could fix this by trying to add a mechanism by which we can use
whitespace within a window name, but it seems like an easier solution
if we just forbid whitespace within a window name.  Not only is this
easier, but I think this is probably the better solution, identifier
names with spaces in would mean we'd need to audit all the places a
window name could be printed and ensure that the use of a space didn't
make the output ambiguous.

So, having decided to disallow whitespace, I then thought about other
special characters.  We currently accept anything as a window name,
and I wondered if this was a good idea.

My concerns were about how special characters used in a window name
might cause confusion, for example, we allow '$' in window names,
which is maybe fine now, but what if one day we wanted to allow
variable expansion when creating new layouts?  Or what about starting
a window name with '-'?  We already support a '-horizontal' option,
what if we want to add more in the future?  Or use of the special
character '{' which has special meaning within a new layout?

In the end I figured it might make sense to place some restrictive
rules in place, and then relax the rules later if/when users complain,
we can consider each relaxation as its requested.

So, I propose that window names should match this regular expression:

  [a-zA-Z][-_.a-zA-Z0-9]*

There is a chance that there is user code in the wild which will break
with the addition of this change, but hopefully adapting to the new
restrictions shouldn't be too difficult.