Remove inconsistent usage of macros that broke Thread.sleep/wait on host

Code for managing Thread.sleep/wait used both !defined(__APPLE__) and
HAVE_POSIX_CLOCKS interchangeably to mean the same thing. That worked when
one or other was set but failed on host because neither were set and could also
fail if they were both set. This changed to use HAVE_POSIX_CLOCKS consistently.

The code that used this was spread across 4 separate files with quite a lot of
duplication so that has been replaced with a new method
dvmInitCondForTimedWait in Sync.cpp.

A few extra comments were added to make some things that were a bit confusing
clearer, hopefully.

Change-Id: I7660c931f0cafcd0563afd1165de2aa615040602
Bug: https://code.google.com/p/android/issues/detail?id=68402
Merge "Remove inconsistent usage of macros that broke Thread.sleep/wait on host"
Track package manager changes for arch specific dexopt.

- Changes signature of isDexOptNeededInternal. No behavioural
  changes are needed because dalvik only uses the first argument
  to the function (the "name") and dexopt is architecture agnostic.

- Changes dexOptGenerateCacheFileName to place dex files under
  /data/dalvik-cache/<instruction-set>. This allows us to avoid
  needing dalvik specific logic in the package manager and installd.

(cherry picked from commit f752d041dac2cc8e26d03292ffec986a2bf905f9)

Change-Id: Ie31c9925269d6ac97d358ce49219557692704329
Merge "Track package manager changes for arch specific dexopt."
Define kInstructionSet for x86-64 and arm64.

This fixes 64-bit host compilation of libdex.

Change-Id: I364b624e12620f844cc7bbaa08e679c8a529f87c
Merge "Define kInstructionSet for x86-64 and arm64."
Return the correct error code in multi-thread mode

Bug: 14062905

In "--num-threads" mode, dx did not return a result code different
than zero in case of a Throwable.
This CL aims to have the same behaviour in multi-threaded mode as in
normal mode.
There are 2 cases:
- When there is an Exception, it is supposed to be handled by
ClassPathOpener.Consumer.onException(). The number of errors is then
incremented, which is used in "com.android.dx.command.dexer.Main" to
return the error code. With "--num-threads" it couldn't be handled by
onException(). So I've modified the ParallelProcessor to use the
ClassPathOpener, so that the Exception is handled inside the thread.
- When there is an Error it is handled using the Futures of
ParallelProcessors through ExecutorService.

Change-Id: Idc9d8d8bc737587ca518f8f9166e5e511ec22908
Remove tests of dead code.

Bug: 14903517
Change-Id: I9fc7dd742e80850eeb461f91be7750530585cfb3
Merge "Remove tests of dead code."
Merge "Return the correct error code in multi-thread mode"