[vmo-utils] Move PinnedVmo from IntelHDA utils into libfzl

Promote the PinnedVmo class out of the IntelHDA driver and up to
libfzl so that it can be used by other drivers.

ZX-2462 #comment PinnedVmo class promoted into libfzl from HDA driver

Test: Build and manual test with existing HDA driver.
Change-Id: I60b2501c906e5ef3a58e9d6f1dc4ded6cfa3a191

[vmo-utils][fzl] Move contents of vmo-utils into fzl

Move copies of the vmo-centric helper classes which existed in
vmo-utils into fzl. This is step one of merging vmo-utils and libfzl.
Once higher level code has been migrated over to use the new library,
vmo-utils and its tests can be removed.

Also, merge the libfzl and fzl unit tests. I'm not sure how they got
divided in the first place, but now they are unified under just
libfzl.

ZX-2462 #comment Classes have been duplicated and added to libfzl
Test: Build and unit-test

Change-Id: Ie3bc07a9f78b6383032fcc974f28dd6af50caf21

[dev][intel-hda][dsp] check FW_STATUS first during FW init

After starting DMA for DSP firmware load, poll the FW_STATUS field
to equal ADSP_FW_STATUS_STATE_ENTER_BASE_FW before waiting for the
FW Ready IPC. Both conditions must be true when the DSP is
operational.

It seems like reading FW_STATUS has some effect. Previously the
driver waited for the FW Ready IPC first, and sometimes the wait
times out with a bad FW_STATUS. If we then poll FW_STATUS, it
transitions to ADSP_FW_STATUS_STATE_ENTER_BASE_FW.

Also stop the DMA after polling FW_STATUS and before waiting
for IPC. This doesn't seem to have an effect.

Test: booted a pixelbook that previously failed at least 1
out of 10 boots, now booted successfully 30 times.
booted a second pixelbook 10 times successfully

ZX-1538 #comment another potential fix

Change-Id: I86989291e7e376f871beea3a0224e8d95323750e

[dev][intel-hda][dsp] keep FW pinned until it is loaded

The FW VMO was getting unpinned while the code loader DMA
was in progress, because the PinnedVmo object was destroyed
on function return from IntelDspCodeLoader::TransferFirmware()
which is not responsible for DMA completion wait.

Move the PinnedVmo object to the function that waits for
firmware load success (implies DMA completion), so the memory
stays pinned.

Change-Id: I207a7ca6a68a448011eea6829251c2040d29d986

[fbl][vmo] Moving VmoMapper out of fbl

The VmoMapper and the VmarManager classes are more
of vmo utilities than fbl libraries. In preparation
for adding more such utilities, I am moving these libraries
to another location.

There are other CLs to update usage of this library in
the other repos.

Change-Id: I610bfd2838cf7843120d4aa885d24ea3b1b97b73

[dev][intel-hda] intel-audio-dsp driver

Currently just boots the DSP and loads the firmware.
The DSP driver is independent from the HDA driver, however
the source is checked in under system/dev/audio/intel-hda/
to be consistent with HDA codecs.

Change-Id: Ic2d9bca68ae7ee6c9011f53d0f894b7a68e43b86