[CORE] Introduce Boot CPU APIs for SMP host

Currently, we were assuming that Xvisor will be always booted on
CPU0 (i.e. "Boot CPU" is CPU0) which can break our SMP booting in
following use-cases:
1. In AMP system, Xvisor might run on M CPUs out of total N CPUs
and these could be any M CPUs.
2. Faulty HW where CPU0 never boots.

To make our SMP booting independent of underlying CPU number, we
introduce concept of "Boot CPU" and related APIs.

As the name suggest, "Boot CPU" is nothing but the CPU on which
Xvisor starts booting. New added APIs related to Boot CPU are:
1. vmm_smp_bootcpu_id() - SMP processor ID of Boot CPU
2. vmm_smp_set_bootcpu() - Mark current CPU as Boot CPU. This
API will only work once for CPU who first calls it.
3. vmm_smp_is_bootcpu() - Check whether current CPU is Boot CPU.

We also depericate vmm_init_secondary() API and make vmm_init()
intelligent to handle Boot CPU and Non-Boot CPUs differently.

Signed-off-by: Anup Patel <anup@brainfault.org>
[DRIVERS] mmc: Reduce delays in SD and MMC card detections

Currently, __sd_send_op_cond() and __mmc_send_op_cond() are used by
__mmc_detect_card_inserted() to detect SD and MMC cards respectively.

These functions have huge trial counts (or "timeout" counts) hence on
some ARM host (such as Raspberry Pi) we might spend lot of time trying
to detect card when no card is present.

This patch make trial counts (or "timeout" counts) in these functions
to more realistic value.

Signed-off-by: Anup Patel <anup@brainfault.org>
[ARM] arm32: Don't access FPSID before enabling CP10 & CP11 in CPACR

Currently, cpu_init() function used cpu_supports_fpu() before enabling
CP10 & CP11 in CPACR. This is architecturally wrong and does not work
on real HW becasue cpu_supports_fpu() reads FPSID which can only be
accessed if CP10 & CP10 is enabled in CPACR.

This patch fixes above described issue for arm32 port.

Signed-off-by: Anup Patel <anup@brainfault.org>
Merge remote-tracking branch 'upstream/master' into A20