Project up check port availability

[schwobaseggl]

When the designated ingress port is already in use, the project fails to come up with an obscure stack trace (this appears to be the same error as in other cases when the k3d cluster fails to be created, e.g. with an incompatible k3d version).

# ...
\[ERROR] Something went completely wrong with the cluster spin up (or we got a timeout).
# ...
File "/home/veit/.local/lib/python3.8/site-packages/src/cli/project.py", line 261, in up
    Telepresence(cluster.storage.get()).start()
  File "/home/veit/.local/lib/python3.8/site-packages/src/local/system.py", line 76, in __init__
    raise ValueError("Project does not contain the kubeconfigPath parameter")
ValueError: Project does not contain the kubeconfigPath parameter

Some foreseeable errors could be checked against in advance (like if the ingress port is available on the host). Also, why not capture the error output of the k3d cluster create command, which in this case would be something like:

ERRO[0021] Failed Cluster Start: Failed to add one or more helper nodes: runtime failed to start node 'k3d-unikube-mumpiz-serverlb': docker failed to start container for node 'k3d-unikube-mumpiz-serverlb': Error response from daemon: driver failed programming external connectivity on endpoint k3d-unikube-mumpiz-serverlb (c58c63548f30caa8b752b2d763ff4990e465e55f6210abe7166e464fdf2004f9): Bind for 0.0.0.0:61348 failed: port is already allocated 
ERRO[0021] Failed to create cluster >>> Rolling Back 

That would immediately reveal the problem.

• check if port(s) already allocated on project up #241

[SteinRobert]

I suggest we collect use cases and work through each of them individually.

[schwobaseggl]

I agree on the issue of gracefully handled specific cases. Let's cross each bridge as we get there.