Add ASL compiler support (ACPI)

[shchuko]

Closes #198

There's no pre-installed iasl compiler under macOS (unlike freebsd). This series of changes adds iasl compiler support. I've found that ACPICA tools can be built under macOS, so its iasl compiler can be given to xhyve to build ACPI Tables. Backward compatibility is saved.

Changes overview:

• ACPI building method can be chosen at runtime (callbacks used):
  • without -a <iasl/compiler/path> option xhyve uses an old method with copying precompiled ACPI to guest mem
  • with -a <iasl/compiler/path> option xhyve uses given asl compiler to build tables
• applied updates to catch up with the newest stable ACPICA 2020052
  • freebsd/freebsd@0ac12a8077d72b50778d64a5b6805b12e7a93164
  • freebsd/freebsd@e7c86565cd6fceca001d4b9b68048ecf0a0f3ea6
• MADT table correction applied (VM_MAXCPU > 21 now supported) freebsd/freebsd@5822161300bbbbfda9919d5f9b011a7ecb192907

[adaugherity]

So, I decided to try this out, and got in way deeper than intended, and have some findings. Disclaimer: speaking as a fellow user -- I am not an xhyve developer.

This seems like a good addition, although I'm unclear when it would be needed and how to fully make use of it. Does this let you add new ACPI tables or modify the built-in ones without recompiling? If so, please add an explanation to the man page.

Speaking of which, the man page should be updated to list this option. I'll point out that -a is already used for something different in bhyve, so might it be wise to pick a different option? Personally, I would leave a compiled in default path (e.g. /usr/local/bin/iasl); it could be easily overridden by building with -DBHYVE_ASL_COMPILER=...). Then the path could be optional, i.e. xhyve [ -a [ /path/to/iasl ] ].

Some minor issues:

• The code as it presently is does not build with make -- missing function prototypes and undefined symbols when linking, but those errors are easily fixed, as I've done in my repo.

• When running a VM with this option, the tables as seen by the VM are the same as without it, but I guess that is to be expected? I do receive a warning from iasl:

  /tmp/bhyve.FIp4RNN     19:     Device (PC00)
  Warning  3073 -           Multiple types ^  (Device object requires either a _HID or _ADR, but not both)

  I have no idea what this means, but it appears to be a problem with the DSDT table supplied by xhyve.

• Style nit: your dsdt_fixup() definition has the opening brace on the same line, but it appears this project uses brace on a new line for functions.