Fix host networking issues and rename incidental issue

[apostasie]

Purported to:

• fix Container create panic (index out of range)  #3345
• fix nerdctl rename broken (with --network host, none) #3341
• fix add-host parameter not valid #2591
• fix Parameter --add-host not working when using also --net=host #2613
• (for the relevant part of) fix hostname is always overwritten by container id in container when using --network=host #2694

Does NOT fix yet #355

The take-away are:

1. the modification to make network=host use the host hostname as a default is straightforward
2. host networking previously did not call Acquire on the hosts store, causing Update to fail during a rename operation. Note that the same is true for none. Rename has been modified to not hard fail anymore on hostsstore Update failures. Another PR (Rename rollback on error #3342) is also making rename able to rollback in case of failure
3. for the same reason as above, extraHosts were not added - this has now been done in SetupNetworking and CleanupNetworking for the hostNetworkManager

Note that calls to CleanupNetworking and SetupNetworking were previously gated by a platform check to apply only on Windows (although not everywhere).
Now, this does not seem to serve much of a purpose, as these methods did nothing for any of the networkManager (with the exception of the Windows implementation of CNI).
Is this some kind of unfinished refactor?

Anyhow, I did remove the platform checks altogether, since the code decides already if something should happen.

[apostasie]

Note that we will not clean-up meta.json if the container exits on its own.

This is similar to #2993 and #1829 and belongs to a more general class of problem with our network / container lifecycle management (be it CNI or not).

@fahedouch proposal on containerd never went anywhere unfortunately (containerd/containerd#8163).

I think we need to re-evaluate our strategy wrt lifecycle cleanup.

[AkihiroSuda]

Thanks