Refactor `vmm` builder code to simplify logic that creates the microVM to boot

Updated on 05/09/2025:

Currently, the logic to create a Vm and a Vmm objects is scattered across vmm/lib.rs and vmm.builder.rs files and it is quite convoluted and some times difficult to follow. Moreover, there is a lot of architecture specific code inserted in arbitrary places which further increases the un-readability.

Currently `Vmm` object is a mix bag of `Vm` related fields and miscellaneous management fields. This makes the whole differentiation between `Vm` and `Vmm` more difficult and testing more convoluted.
The goal of this issue is to move all `Vm` related fields (`vcpus_handles`, `device_manager` and `device_manager`) into `Vm`. This also goes for all `attach_*_device` functions and unit tests from `builder.rs`
The final solution should have approximately this look:
```rust
pub fn build_microvm_for_boot(
instance_info: &InstanceInfo,
vm_resources: &super::resources::VmResources,
event_manager: &mut EventManager,
seccomp_filters: &BpfThreadMap,
) -> Result>, StartMicrovmError> {
// vm_resources verification

// All Kvm, Vcpu creation and device attachment can
// happen here
let vm = Vm::new(vm_resources, event_manager)?;
// or move registration into separate function
let vm = Vm::new(vm_resources)?;
vm.register_device_events(event_manager)?;

let vmm = Vmm {
vm,
...
};

// GDB configuration

vmm.vm.start_vcpus(...vcpu seccomp filter)?;
...
}
```

Start by reading vmm/lib.rs and vmm.builder.rs, tracing how Vm and Vmm are created and how architecture-specific code and device attachment are arranged. Review the unit tests in builder.rs before refactoring. Done means Vm owns the listed Vm-related fields and attach_*_device functions, Vmm construction follows the proposed separation, and the affected tests pass.

Written by the indexing model from the issue text.