[zxcrypt] Allow smoother transition to TEE-backed keys

The original implementation offered only two options for zxcrypt's
key-source policy: always use the TEE, or always use a null key.

For a variety of reasons, including avoiding immediately losing data in
an OTA moving from the null keysource to the TEE keysource, we'd like to
be able to make a smoother transition, where we might try to use the TEE
if possible but be willing to fall back to the null key.  This patchset
expands our options by also allowing a policy for "opportunistically try
the TEE, but fall back to the null key if that fails for any reason" and
"require the TEE for new volumes, but still try the null key to unseal
existing volumes".  The former is safe to deploy even if we're waiting
on bootloader changes to land to enable the keysafe TA, and the latter
helps start the clock on devices which aren't using TEE-backed keys.

After spending sufficiently long with a board configured as
"tee-transitional", we can safely cut the config value over to "tee"
(required) since most devices will have been paved with a new zxcrypt
volume, which will be using a TEE-backed key.

Tests: With a modified bootloader and the keysafe TA included in the
system image, I OTA'd an Astro from "null" to "tee-opportunistic" to
"tee-transitional" without data loss.  I then repaved the Astro under
"tee-opportunistic", then OTA'd to "tee-transitional" and then to "tee",
and observed that each came up and successfully unlocked the /data
volume.  I also added unit test coverage.

SEC-270 #comment

Change-Id: I0fb95e5322468da4e13004e21569f44385d8d8c8