Enhancements in the LXC Spawner towards feature parity

[clebergnu]

Is your feature request related to a problem? Please describe.
The LXC Spawner is about to be integrated into Avocado. Most users probably won't be well versed on its current differences from the process and podman spawners, but given that it's an opt-in feature, it should not impact regular users.

Even so, there's no reason why the LXC Spawner can not be made to work just like the other spawner implementations.

Describe the solution you'd like
Allow users to get as closely as possible to experiences such as:

1. avocado run -- /reference/to/test
2. avocado run --spawner=podman -- /reference/to/test
3. avocado run --spawner=lxc -- /reference/to/test

Describe alternatives you've considered
The other alternative solution is having spawners that do not present the same experience, which is not desirable.

Additional information
The following issues are known at this time, and need to addressed to implement feature parity:

• Have documentation on the LXC Spawner set up and on its current differences/limitations
• Support the deployment of Avocado itself in the container environments, removing one extra customization step
• Support for automatic status server (currently users may need to supply something like --status-server-disable-auto --status-server-listen=192.168.122.1:9999 --status-server-uri=192.168.122.1:9999)
• Support for task's output_dir, that is, test's output within the that directory in the LXC container will be available on the job transparently

[pevogam]

@clebergnu Feel free to assign me on this. Should we/I create sub-issues about separate important points here where we could also coordinate? Let me know how you would prefer to proceed here.