Canonicalizes paths when attempting to compensate for odd mvnw working-directory echo bug

[briandealwis]

There is an odd bug in some mvnw wrappers (particularly the one generated by the Spring Initializr) where it prints out the current directory name. This bug affects the Scaffold-Jib integration as Skaffold requests mvnw jib:_skaffold-files. For example:

$ pwd
/Users/bsd/Projects/skaffold-jib/spring-boot-logging

$ ./mvnw -q jib:_skaffold-files
/Users/bsd/Projects/skaffold-jib/spring-boot-logging
/Users/bsd/Manumitting/Projects/skaffold-jib/spring-boot-logging/pom.xml
/Users/bsd/Manumitting/Projects/skaffold-jib/spring-boot-logging/src/main/java
/Users/bsd/Manumitting/Projects/skaffold-jib/spring-boot-logging/src/main/resources
/Users/bsd/Manumitting/Projects/skaffold-jib/spring-boot-logging/src/main/resources
/Users/bsd/Manumitting/Projects/skaffold-jib/spring-boot-logging/src/main/jib

A consequence is that Skaffold then monitors the entire source directory and picks up files from the build, and continuously triggers new builds.

To compensate, the Scaffold-Jib dependencies parser compares each path to the workspace directory. But there are two problems:

1. The workspace directory is the context field value and is usually relative to the current working directory, whereas the files reported by jib:_skaffold-files are absolute.
2. I have a symlink from /Users/bsd/Projects/skaffold-jib to /Users/bsd/Manumitting/Projects/skaffold-jib. So just using filepath.Abs is insufficient as it does not expand symlinks.

This patch adds a util.Canonical(path) method that attempts to expand a provided path, and uses this new method to compare canonicalized paths.

[briandealwis]

Odd, I'm now seeing this error too.

[briandealwis]

I thought jib:_skaffold-files returned canonical file paths, but it does not.
Ah: jib:_skaffold-files does return canonical file paths, but the test in pkg/skaffold/jib/jib_test.go does not. It's probably safest to just canonicalize files in the comparison.

Even, better, use os.SameFile().

[briandealwis]

Closing in favour of #1167.