Use runtime code generation to create implementations

[nitsanw]

This allows:

1. minimal boilerplate for padding (+ runtime decision on pad size)
2. parametrized constants
3. code optimization based on runtime info
   The trade off is code bloat.

[nitsanw]

This is enabled by @RichardWarburton contribution of the template code used for channels.

[nitsanw]

Copying over comment from #61 @plokhotnyuk :
"What about generation of queue implementations?

Let us imagine that we can select desired options:

• allowed number of producer and consumer threads (MPMC, MPSC, SPMC, SPSC);
• underlying data structure (array, list, mixed);
• max size & overflow behavior (unbounded, bounded, overwrite-oldest, etc.);
• forward progress guarantees for producer and consumers (blocking, lock-free and wait-free where it possible);
• memory layout optimizations (@contended, generated padding for old JDKs, etc.);
• memory access optimizations (use Atomic primitive/updaters or Unsafe);
• API (Java collection, FP-style with handler function, etc.).

And then put them to code generator which will produce implementation, generational (property based) and stress tests, suit of benchmarks. "

[nitsanw]

Copying comments from #33 @nitsanw and @georges-gomes :
"This would be hugely helpful and could be considered a completely separate tool/lib. This is an extended alternative to @contended annotation which should allow for field groups. E.g.:

class Foo extends Bar {
  @GroupLayout(id=0,prepad=64)
  @FieldLayout(group=0)
  int a;
  @FieldLayout(group=0)
  int b;
  @FieldLayout(group=1)
  byte c;
}

Will result in a hierarchy being generated such that fields are ordered and padded:

abstract class FooPrePadding extends Bar {
  long p0,p1,...;
}
abstract class FooFields1 extends FooPrePadding {
  int a;
  int b;
}
abstract class FooFields2 extends FooFields1 {
  byte c;
}
class Foo extends FooFields2 {
}"

"If you go the codegen route, I was thinking of also generating multiple versions of the Queues for different constant like sparse-shift 0 vs 2. Just to benefit from the static final performance.

class ConcurrentCircularArrayQueue<E> extends ConcurrentCircularArrayQueueL0Pad<E> {
@Shape(LowMemory=0, HighPerf=2) 
protected static final int SPARSE_SHIFT = 0;

this would generate 2 classes:

• ConcurrentCircularArrayQueueLowMemory
• ConcurrentCircularArrayQueueHighPerf"