Fixed path-relativization error when traversing different partitions (#658)

It happened on MacOSX, but I do not exclude it may happen in other OS
too: when building some large sketch for Arduino Due, the system libsam_xxx.a
library is transformed to relative path, in particular the path

/Users/cmaglie/Library/Arduino15/packages/arduino/hardware/sam/1.6.12/variants/arduino_due_x/libsam_sam3x8e_gcc_rel.a

is made relative to the build folder

/var/folder/x8/ttjf_wrd63823894128467832/T/arduino_build_988374/

but since both paths resides in different partitions the result is:

../../../../../../Users/cmaglie/Library/Arduino15/packages/arduino/hardware/sam/1.6.12/variants/arduino_due_x/libsam_sam3x8e_gcc_rel.a

so it traverse from /var/..../arduino_buil_988374 to the root and descend back into /Users

This is bad for two reasons:

1) the resulting "relative" path is longer than the original "absolute"
path, defeating the purpose of the transformation.

2) for some weird reason gcc is unable to find the libsam file using the
relative path. It seems that when running inside /var/... it cannot "escape" to
/Users/...

This patch avoid the situation above by adding a check for the presence
of ".." in the resulting path (basically avoiding path relativization
outside of the build folder) and by checking that the resulting path is
shorter than the original absolute path.

Author: cmaglie

legacy/builder/utils/utils.go

@@ -207,7 +207,7 @@ func PrepareCommandFilteredArgs(pattern string, filter argFilterFunc, logger i18
 			if relativePath != "" {
 				if _, err := os.Stat(part); !os.IsNotExist(err) {
 					tmp, err := filepath.Rel(relativePath, part)
-					if err == nil {
+					if err == nil && !strings.Contains(tmp, "..") && len(tmp) < len(part) {
 						part = tmp
 					}
 				}