How many clowns path deps can you fit in a clown car one line of code?

During review of Gateway API refactor from #176, I've realized there are cases, when we use three "path types" from three different libraries. This culminated in this fun one-liner:

imPath, err := NewImmutablePath(ifacepath.New(ipath.String()))

• ipath is https://github.com/ipfs/go-path (includes resolvers, see Allow injecting custom path resolvers. kubo#9750)
  • bonus: old vendored version in https://github.com/filecoin-project/lotus/tree/master/lib/oldpath
• ipfspath is https://github.com/ipfs/interface-go-ipfs-core/tree/master/path
• ImmutablePath is recent invention in go-libipfs/gateway because above did not provide a type for representing this state

Proposed path forward

Thoughts on deduplicating/consolidating under boxo/path?
It honestly feels like if go-libipfs has a purpose, it is to provide a solution for reusable things like this.

I feel we will make better Gateway API in #176 if we don't use ifacepath but use a single go-libipfs/path library that covers Path, Immutable and Resolved states with distinct types/interfaces.

I assume we want to follow "copy" strategy from #191 here, to minimize blast radius?

We could make this consolidation in steps, first switch gateway, so the public interface from #176 only uses types from boxo/path, and in the future switch namesys/kubo to that as well.

Things to look out for

During the consolidation, the following issues and Pull Requests from the relevant repositories should be taken into consideration.

• CIDs containing "/" cannot be parsed go-path#54
• Fix/remove deprecated logging go-path#29
• path: add ToCid API go-path#61
• Support relative paths interface-go-ipfs-core#15
• Path parsing, validating, and normalizing. interface-go-ipfs-core#33

cc @ipfs/kubo-maintainers for feedback (paths are everywhere, and as much as I'd like to clean this up, I don't want to add unnecessary work for anyone)