Add error handling in AML bytecode creation code

[bchalios]

Changes

Change the acpi_tables::aml::Aml trait methods to return Result types and adapt all the relevant implementations. Also, add a check in the methods that create acpi_tables::aml::AddressSpace<T> types, to check that the address ranges are reasonable, i.e. first address is not bigger than the last address of the address space.

Reason

The first change allows us to substitute a handful of panic!s and assert!s with proper error handling. The second change avoids a potential underflow when we calculate the length of the address space.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

• If a specific issue led to this PR, this PR closes the issue.
• The description of changes is clear and encompassing.
• Any required documentation changes (code and docs) are included in this
  PR.
• API changes follow the Runbook for Firecracker API changes.
• User-facing changes are mentioned in CHANGELOG.md.
• All added/changed functionality is tested.
• New TODOs link to an issue.
• Commits meet
  contribution quality standards.

---

• This functionality cannot be added in rust-vmm.

[codecov]

Codecov Report

Attention: Patch coverage is 91.86047% with 21 lines in your changes missing coverage. Please review.

Project coverage is 84.05%. Comparing base (ccb3c8f) to head (788b3f9).
Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
src/acpi-tables/src/aml.rs	91.25%	16 Missing ⚠️
src/vmm/src/device_manager/acpi.rs	94.28%	2 Missing ⚠️
src/vmm/src/device_manager/legacy.rs	93.75%	1 Missing ⚠️
src/vmm/src/device_manager/mmio.rs	92.85%	1 Missing ⚠️
src/vmm/src/devices/acpi/vmgenid.rs	85.71%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4870      +/-   ##
==========================================
- Coverage   84.08%   84.05%   -0.03%     
==========================================
  Files         251      251              
  Lines       28060    28096      +36     
==========================================
+ Hits        23594    23616      +22     
- Misses       4466     4480      +14     

Flag	Coverage Δ
5.10-c5n.metal	84.67% <91.86%> (-0.05%)	⬇️
5.10-m5n.metal	84.66% <91.86%> (-0.05%)	⬇️
5.10-m6a.metal	83.97% <91.86%> (-0.04%)	⬇️
5.10-m6g.metal	80.73% <74.22%> (+0.02%)	⬆️
5.10-m6i.metal	84.65% <91.86%> (-0.05%)	⬇️
5.10-m7g.metal	80.73% <74.22%> (+0.02%)	⬆️
6.1-c5n.metal	84.67% <91.86%> (-0.04%)	⬇️
6.1-m5n.metal	84.66% <91.86%> (?)
6.1-m6a.metal	83.96% <91.86%> (-0.04%)	⬇️
6.1-m6g.metal	80.72% <74.22%> (+0.01%)	⬆️
6.1-m6i.metal	84.65% <91.86%> (-0.04%)	⬇️
6.1-m7g.metal	80.73% <74.22%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ShadowCurse]

I am not sure errors are better in this case. If we fail in acpi tables creation there is no way to recover. Having code to panic or having it to propagate all the way to main has same result of application exiting with an error. But in case of returning errors we need to do all this error creation/propagation and without way to handle the error all this effort is for nothing. With panic! and assert! we get same behavior without burden of creating results/errors everywhere.

Update:
After some offline discussion it seems this change is unavoidable because we want to upstream this code and using errors in this case is a more standard approach.