Loaders should abstract the arch_timer frequency

[r1mikey]

The Arm documentation makes three statements about _cntfrqel0:

1. This register is provided so that software can discover the frequency of the system counter.
2. It must be programmed with this value as part of system initialization.
3. The value of the register is not interpreted by hardware.

This register is documented as being conditionally writable, so it's complicated.

if IsHighestEL(PSTATE.EL) then
    CNTFRQ_EL0 = X[t, 64];
else
    UNDEFINED;

Since inetboot is our only loader that can be directly executed (in the qemu boot case for FDT systems), it is also the only loader that can take any meaningful action, but the ACPI loader should set up the system to look the same to unix for the sake of simplicity.

In the inetboot case:

• Find the generic timer frequency as it already does today and set that value in _xbootinfo for consumption by unix.
• unix should simply use the _xbootinfo value when non-zero and fall back to the programmed _cntfrqel0 when non-zero.

In the ACPI/UEFI case:

• The stub must assume that the firmware has programmed the _cntfrqel0 register appropriately.
• The stub must read _cntfrqel0 and populate it in _xbootinfo.
• unix should simply use the _xbootinfo value when non-zero and fall back to the programmed _cntfrqel0 when non-zero.

Effectively, we replace any firmware-lookup interface with inspection of _xbootinfo and maintain the (now unnecessary) fallback to _cntfrqel0.

[r1mikey]

Fix up usr/src/uts/armv8/os/arch_timer.c - timer_freq needs to be renamed and made visible, then set very early. Maybe use an accessor function.