Now that struct vm and struct vcpu are defined in headers, provide
inline accessors.  We could just remove the accessors outright, but they
don't hurt and it would result in unneeded churn.

As a part of this, consolidate definitions related to struct
vm_eventinfo as well.  I'm not sure if struct vm_eventinfo is really
needed anymore, now that vmmops_run implementations can directly access
vm and vcpu fields, but this can be resolved later.

No functional change intended.

MFC after:	2 months
Sponsored by:	The FreeBSD Foundation
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D53586

Now that the machine-independent fields of struct vm and struct vcpu are
available in a header, we can move lots of duplicated code into
sys/dev/vmm/vmm_vm.c.  This change does exactly that.

No functional change intended.

MFC after:	2 months
Sponsored by:	The FreeBSD Foundation
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D53585

There is quite a lot of duplication of code between amd64, arm64 and
riscv with respect to VM and vCPU state management.  This is a bit
tricky to resolve since struct vm and struct vcpu are private to vmm.c
and both structures contain a mix of machine-dependent and
machine-independent fields.

To allow deduplication without also introducing a lot of churn, follow
the approach of struct pcpu and 1) lift the definitions of those
structures into a new header, sys/dev/vmm/vmm_vm.h, and 2) define
machine-dependent macros, VMM_VM_MD_FIELDS and VMM_VCPU_MD_FIELDS which
lay out the machine-dependent fields.

One disadvantage of this approach is that the two structures are no
longer private to vmm.c, but I think this is acceptable.

No functional change intended.  A follow-up change will move a good deal
of machine/vmm/vmm.c into sys/dev/vmm/vmm_vm.c.

MFC after:	2 months
Sponsored by:	The FreeBSD Foundation
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D53584