UI review: Key.id() was: jshell commands

[Brian Goetz]

> All the above are API level.  The API doesn’t know anything about start-up files or list filtering. Or commands for that matter.

And, the mapping from "id" as seen by the command-line shell in commands 
like /drop need not match the IDs in the API.  This discussion is about 
"what should the user see."

The user sees that every command entered has a (currently numeric) 
"handle", and some commands will take such handles as input.  /list and 
/list all shows known snippets along with their handles; /list all shows 
more snippets than /list.

Still, from a user-model perspective, I think it's a bug that

repl> 1 + 1
repl> 2 + 2
repl> /list

yields

   9: 1+1
   10: 2+2

It's a total WTF for the user.

There are a few reasons why something doesn't show up in /list:
  - It was part of the startup
  - It was a bogus snippet
  - It replaces an existing key

Is that complete?

> (5) /list, by default, shows interactively entered active (not failed, dropped, or withdrawn) snippets in id() order.
> (6) That means, even if there are no start-up entries (-nostartup), /list won’t necessarily start with “1” since your first entries may have failed.
> (7) The last entered snippet might not be the last listed in /list if it has the same Key of a previously entered snippet.
> (8) /list all — shows snippets from the start-up, from /open, it shows failed, dropped, and withdrawn snippets.

None of these seem like good arguments against the proposed approach. 
If the user enters well-behaved snippets, snippets will start at (1), 
and temporaries will line up with "line numbers".  The /list header text 
can be amended to:

repl> /list

     [ some entries suppressed, enter /list all to see ]
     1: 1+1
     3: $1 + 1

repl> /list all

     startup.1: import java.util.*
     1: 1+1
     2: blargle(*$#$^N%#$)(
     3: $1 + 1

possibly adorning "2" with something indicating its status.