Layout of inline type in flattened array is calculated incorrectly.

Strongly believe that layout inline types in flattened arrays:
- should be as denser as possible
- single field inline type should have the same layout as array of the type of the field
- inline type free of reference fields shouldn't have different layout for +/-UseCompressedOops

Checked inline types:
TypeB - <boolean>
TypeC - <char>
TypeI - <int>
TypeL - <long>
TypeF - <float>
TypeD - <double>
TypeII - <int, int>
TypeLL - <long, long>
TypeDD - <double, double>
TypeLI - <long, int>
TypeIL - <int, long>
TypeDI - <double, int>
TypeID - <int, double>

Results:
used notation: sizeof(array type) = <array size in bytes>; <calculated size of 1 element in bytes>;

-XX:+UseCompressedOops (array header size = 16 bytes)
sizeof(TypeB[10]) = 32; 1; good
sizeof(TypeC[10]) = 40; 2; good
sizeof(TypeI[10]) = 56; 4; good
sizeof(TypeL[10]) = 176; 16; BAD
sizeof(TypeF[10]) = 56; 4; good
sizeof(TypeD[10]) = 176; 16; BAD
sizeof(TypeII[10])= 96; 8; good
sizeof(TypeLL[10])= 336; 32; BAD
sizeof(TypeDD[10])= 336; 32; BAD
sizeof(TypeLI[10])= 176; 16; good
sizeof(TypeIL[10])= 176; 16; good
sizeof(TypeDI[10])= 176; 16; good
sizeof(TypeID[10])= 176; 16; good

-XX:-UseCompressedOops(array header size = 24 bytes)
sizeof(TypeB[10]) = 104; 8; BAD
sizeof(TypeC[10]) = 104; 8; BAD
sizeof(TypeI[10]) = 104; 8; BAD
sizeof(TypeL[10]) = 104; 8; good
sizeof(TypeF[10]) = 104; 8; BAD
sizeof(TypeD[10]) = 104; 8; good
sizeof(TypeII[10])= 104; 8; good
sizeof(TypeLL[10])= 184; 16; good
sizeof(TypeDD[10])= 184; 16; good
sizeof(TypeLI[10])= 184; 16; good
sizeof(TypeIL[10])= 184; 16; good
sizeof(TypeDI[10])= 184; 16; good
sizeof(TypeID[10])= 184; 16; good


How to reproduce:
- Everything is wrapped to JMH for convenience
- location: http://cr.openjdk.java.net/~skuksenko/valhalla/8238369/


Way 1:
 Based on "Class::getObjectSize" method.
 Run:
   java -jar benchmarks.jar Size0
 and check std output.

Way 2:
 Based on JMH GC startistics.
 Run:
    java -jar benchmarks.jar Size1 -prof gc
 In results look into normalized GC allocation rate:
 
 Size1.allocDD:·gc.alloc.rate.norm 10 avgt 5 336.017 ± 0.002 B/op

Way 3:
 Checking assembly.
 It is very difficult to extract proper array offset from generated when HotSpot did aggressive vectorization.
 Isolated benchmarks were created.
 Run:
    java -jar benchmarks.jar Size2 -prof perfasm
 
 Look into asm code for methods "from<typeID>"
 e.g.
c2, level 4, org.openjdk.valhalla.sizes.Size2::fromDD, version 476 (141 bytes)
          [Verified Entry Point]
          [Verified Value Entry Point]
          [Verified Value Entry Point (RO)]
            # this: rsi:rsi = &apos;org/openjdk/valhalla/sizes/Size2&apos;
            # parm0: rdx:rdx = object
            # parm1: rcx = int
            # [sp+0x30] (sp of caller)
  0.91% 0x00007effebfa6870: mov %eax,-0x14000(%rsp)
  0.91% 0x00007effebfa6877: push %rbp
  1.10% 0x00007effebfa6878: sub $0x20,%rsp
  0.13% 0x00007effebfa687c: mov 0xc(%rdx),%r10d ; implicit exception: dispatches to 0x00007effebfa6940
  0.08% 0x00007effebfa6880: cmp %r10d,%ecx
            0x00007effebfa6883: jae 0x00007effebfa691b
  0.66% 0x00007effebfa6889: movslq %ecx,%r10
  0.11% 0x00007effebfa688c: shl $0x5,%r10 ;*synchronization entry
                                                                      ; - org.openjdk.valhalla.sizes.Size2::fromDD@-1 (line 147)
  0.11% 0x00007effebfa6890: vmovsd 0x10(%rdx,%r10,1),%xmm0
            ...
            
"shl $0x5,%r10" - TypeDD has 32 bytes size.