Enum enhancement

[Brian Goetz]

> I really like Tagir's suggestion about (2): Optional<E> findValue(String
> name)

Yes, it has an attractive cost-benefit.

> But this leads me to a question regarding Map... Have you ever considered
> adding the equivalent default method to the Map interface?

Why yes, yes we have ;)

The tl;dr: version is: we're not touching this until Valhalla.

First, note that Map::get uses `null` as a sentinel for "not found".  
What does this do when we have a `Map<String,int>`? Box?  Yuck.  
`Map::get` is called way too often to tolerate this kind of boxing.

Similarly, if we were to add this method now, we'd have the same 
problem; Optional is a heavyweight object box.  Again, Map::get is 
called way too often to tolerate this.  (When Optional is a value, 
different story.)

So, how would we design fetching from a Map if we knew there were some 
types that were non-nullable?  Well, lots of options, each with pros and 
cons:

     - Like what we have today, but which returns a nullable type: `V? 
get(K key)`
     - A version that takes a user-provided sentinel to express "not 
found", such as `V get(K key, V sentinel)`
     - A version that takes a lambda: `boolean get(K key, Consumer<V> 
lambda)`
     - An optional-bearing version, such as `Optional<V> get(K key)`
     - A pattern match: `if m matches Map.withMapping(k, var v)`
     - more...

The design space here is pretty big.  The requirements on the language 
(nullable types?  pattern matching?  value optionals?) range all over 
the map too.  For each of them, they are really convenient for some use 
cases but really inconvenient for others. Should we require Map 
implementations to implement all of them?

As you can see, this is far from a "why not just..." sort of question.