Primitive Queue<any T> considerations

[Doug Lea]

We considered most of these issues when designing jdk8 Spliterator,
which was created with possible any-fication in mind
(and emulated in jdk8 IntStream etc). This led to using
   boolean Spliterator::tryAdvance(Consumer<T> action)

This avoids need for defaults or shadow bits or boxes,
at the expense of placing more pressure on optimizing
lambdas, which can still be an issue.

We briefly considered also adding the similar
   boolean Queue::tryConsume(Consumer<T> action)
... and similarly in a few other APIs. In retrospect, we probably ought
to have done this in jdk8, since it seems almost inevitable that
they will be added when any-fication happens.
People don't have to use them of course, but when they don't,
they will have to rely on boxing and/or Optional for
possibly-null-returning methods.

-Doug