Don't assume Slot 3, Drive 2 is /RAM

[inexorabletash]

While Slot 3, Drive 2 (unit number $Bx) will never be assigned to anything other than /RAM by ProDOS (as $BF), there are scenarios where this might be repurposed. One is VEDRIVE which might assign $3x/$Bx if they are not already in use. This would require:

• Booting ProDOS
• Using a utility to disconnect /RAM and free up unit $BF
• Initializing VEDRIVE when nothing else is free. VEDRIVE will create unit number $B0 for the second unit.

Consequences:

• On startup (via lib/disconnect_ram.s), DeskTop will search for $Bx and disconnect it
• On exit, DeskTop will reconnect it and try to FORMAT it, which is probably not good.

Plausible path:

• DeskTop scans for unit $Bx. ProDOS 1.x, 2.0.x, and 2.4.x creates /RAM with unit $BF. The ProDOS 8 Technical Reference Manual says that "Its unit number, as entered in
  the ProDOS global page's device list, is $BF." and later mentions that "/RAM'S DEVICE NUMBER IS $BF. THUS THIS CONVENTION WILL ALLOW OTHER DEVICES THAT DO NOT NECESSARILY RESEMBLE (OR IN FACT, ARE COMPLETELY DIFFERENT FROM) /RAM TO REMAIN INTACT IN THE SYSTEM.". But it then goes on to give code that looks for $BF, $BB, $B7, or $B3. We could follow that (why????) or hard-code $BF
• Glen E. Bredon's RAM.DRV.SYSTEM disconnects /RAM entirely and replaces it with a Slot 3 Drive 1 entry, so not an issue.
• John Brook's RAMAUX.SYSTEM creates a separate /RAMA $3F (RamWorks expanded memory) and /RAM $BF (just for Aux), so it's fine.
• ProDOS 2.5 alpha 8 creates /RAM as $B0 since it changes the usage of the low bits of the unit number. This is problematic, but we don't support ProDOS 2.5 right now.

Note that in this case it's possible to have 14 actual volumes, so the definition in desktop/internal.inc kMaxVolumes = kMaxDevListSize - 1 will need to change, and a grid location for one more volume will need to be added.

(While we're here, we could bump that up to 15 to support Slot 0, Drive 2. But maybe that's going too far.)

cc: @apple2geek