RFR: JDK-8205336: Modularize allocations in assembler

[Roman Kennke]

Much like GC should own allocation paths in the runtime, we need to do
the same in assembler (which covers interpreter and C1). See also:

https://bugs.openjdk.java.net/browse/JDK-8204803

In Shenandoah we need to allocate some extra space and initialize the
fwd ptr of each object. More generally, I am of the opinion that it
should be up to the GC implementation how and where to allocate objects.
The proposed change achieves that for interpreter and C1. Only tlab
allocation and eden allocation paths are relevant here, everything else
goes via slowpath/runtime allocation, which is already covered by
JDK-8204803.

The change does (for x86 and aarch64):
- fold incr_allocated_bytes() into MA::eden_allocate(). The two always
come in pairs, they can just as well call incr_allocate() from
eden_allocate(). This has the additional advantage that it doesn't
generate dead code for GCs that don't support eden allocations at all.
(Before it used to generate code for incr_allocated_bytes() but jump
over it unconditionally).
- Move implementations of both tlab_allocate() and eden_allocate() to
BarrierSetAssembler. The methods in MacroAssembler now call the
corresponding BSA methods.


http://cr.openjdk.java.net/~rkennke/JDK-8205336/webrev.00/

Can I please get reviews?

Thanks, Roman