- Merge sys/sparc64/creator/creator_upa.c into sys/dev/fb/creator.c.

- Merge sys/sparc64/creator/creator_upa.c into sys/dev/fb/creator.c.
  The separate bus front-end was inherited from the OpenBSD creator(4),
  which at that time had a mainbus(4) (for USI/II machines, which use
  an UPA interconnection bus as the nexus) and an upa(4) (for USIII
  machines, which use a subordinate/slave UPA bus hanging off from the
  Fireplane/Safari interconnection bus) front-end. With FreeBSD and
  newbus there is/will be no need to have two separate bus front-ends
  for these busses, so we can easily coallapse the shared front-end
  and the back-end into a single source file (note that the FreeBSD
  creator_upa.c was misnomer anyway; based on what it actually attached
  to that should have been creator_nexus.c), actually OpenBSD meanwhile
  also has moved to a shared front-end and a single source file. Due
  to the low-level console support creator.c also wasn't free from bus
  related things before.
  While at it, also split sys/sparc64/creator/creator.h into a
  sys/dev/fb/creatorreg.h that only contains register macros and move
  the structures to the top of sys/dev/fb/creator.c as suggested by
  style(9) so creator(4) is no longer scattered over two directories.
- Use OF_decode_addr()/sparc64_fake_bustag() to obtain the bus tags and
  handles for the low-level console support instead of hardcoding
  support for AFB/FFB hanging off from nexus(4) only. This is part 2/4
  of allowing creator(4) to work in USIII machines (which have a UPA
  bus hanging off from the Fireplane/Safari bus reflected by the nexus),
  which already makes it work as the low-level console there.
- Allocate resources in the bus attach routine regardless of whether
  creator(4) is used as for the low-level console and thus the required
  bus tags and handles have been already obtained or not so the resources
  are marked as taken in the respective RMAN.
- For both obtaining the bus tags and handles for the low-level console
  support as well as allocating the corresponding resources in the
  regular bus attach routine don't bother to get all for the maximum of
  24 register banks but only (for) the two tag/handle pairs required for
  providing the video interface for syscons(4) support. If we can't
  allocate the rest of them just limit the memory range accessible via
  creator_fb_mmap() accordingly.
- Sanity check the memory range spanned by the first and last resources
  and the resources in between as far as possible, as the XFree86/Xorg
  sunffb(4) expects to be able to access the whole region, even though
  the backing resources are actually non-continuous. Limit and check
  the memory range accessible via creator_fb_mmap() accordingly.
- Reduce the size of buffers for OFW properties to what they actually
  need to hold.
- Rename some tables to creator_<foo> for consistency.
- Also for the sizes in the creator_fb_mmap() mapping table entries use
  macros for consistency, add macros for the remaining register banks
  for completeness.