In current implementation DexFile.prepare takes a list of CstIndexMap
Those maps hold nondistinct constants, which are interned into
Sections. Because they are nondistinct, many intern attempts fail.
When compiling Music app incrementally it is 362980 failed intern
attempts vs only 142850 succesful. We can very easily save that time,
by passing to DexFile.prepare sets of distinct constants that we
compute in ConstantManager. This saves ~100ms of time.

Change-Id: Iaf8ba352f0619600642b103b3537b74608ba2f1e

When compiling Music app incrementally Jack creates 417354 instances
of DexBuffer.Section. Most of them are created internally just to
call a method on them. This patch introduces an internal section
which is reused for those internal purposes. This reduces number of
created objects by 315577, which is around 8 MB.

Change-Id: Ic28dab607095d82879461e60efff2db3dfc62f13

- It is only mandatory to run it before Phi type resolver.

Change-Id: Id0eb78d58e4ac7eadb35079322e8cdf210dac79a

Change-Id: I22068beaf08258e6e5c7a80e101e4aed682bd564

- Try to reuse same objects (CstString, CstType and so on) each time
that it is possible.
- Replace maps by arrays when it is possible.

Change-Id: I227326bd9eb707b94a4edd8761ac06766078362f

Change-Id: Ia28ac670894233f7434053b66fb8d6664f92d2fa

Change-Id: I3cec0e9d56f55e5d784343573f99cd668b3727f2

Profiler showed that during a Music app compilation we create
1,364,332 instances of CstStrings. They require allocation of
395MB which is 6.4% of all memory allocated. It requires 5,457,328
allocations. Most of them is done in stringToUtf8Bytes. Fortunately
only 157,495 instances actually uses the |bytes| field. This means that
if we create |bytes| lazily then we can save a lot of memory and cpu
(stringToUtf8Bytes is also a cpu hotspot).

This change makes |bytes| in CtsString lazily computed.

For Music app the memory allocation is reduced by 353MB which is 5.6% of
all memory allocated. It also saves us 3,788,436 allocations.

Change-Id: I8f2980be07da29d31fc639543dfb9b3966c8cd4e