Normalize micromba relative prefix `-p` behaviour

[AntoinePrv]

Depending on the value passed to micromamba create -p <VAL>, micromamba (mamba ?) behave differently.

micromamba create -p ./env xeus-octave

Working as intended

• ✅ Environment created in ${PWD}/env
• ✅ Prefix replacement during linking is made absolute (cat env/share/jupyter/kernels/xoctave/kernel.json shows /home/.../env/bin/xoctave)

micromamba create -p env/ xeus-octave

• ✅ Environment created in ${PWD}/env
• ❌ Prefix replacement during linking is note made absolute (cat env/share/jupyter/kernels/xoctave/kernel.json shows relative env/bin/xoctave)

micromamba create -p env xeus-octave

• ❌ Environment created as in -n env
• ✅ Prefix replacement during linking is made absolute (cat env/share/jupyter/kernels/xoctave/kernel.json shows /home/.../env/bin/xoctave)

This last one may be more polemic, in fact it seems intended. micromamba is showing a warning

warning  libmamba 'env' does not contain any filesystem separator.
    It will be handled as env name, resulting to the following

I'd argue that this is a bad behaviour.

• The warning is easily missed since micromamba moves on to printing information about download and linking.
• The -p argument was explicitly provided. We are not in a situation where an argument was unnamed and has to be interpreted. It is not common, even surprising, to reinterpret an argument based on its value when the meaning of the argument was already clear.
• The current feature is not documented and may be hard to debug in scripts.

[Klaim]

I'd argue that this is a bad behaviour.

I agree. Also with the whole description, it's confusing and error-prone.