Document an already true fact about PathSegment's zero value.

I... honestly hadn't even realized this before; I just noticed it
when making a refactor that would produce this end state, and thought
"oh, that's silly".  Evidently... it's fine, since this has already
been the case, and not been problematic!  Alright then.
Apparently it's not too silly after all.

pathSegment.go

@@ -6,6 +6,12 @@ import (
 
 // PathSegment can describe either a key in a map, or an index in a list.
 //
+// Create a PathSegment via either ParsePathSegment, PathSegmentOfString,
+// or PathSegmentOfInt; or, via one of the constructors of Path,
+// which will implicitly create PathSegment internally.
+// Using PathSegment's natural zero value directly is discouraged
+// (it will act like ParsePathSegment("0"), which likely not what you'd expect).
+//
 // Path segments are "stringly typed" -- they may be interpreted as either strings or ints depending on context.
 // A path segment of "123" will be used as a string when traversing a node of map kind;
 // and it will be converted to an integer when traversing a node of list kind.

path_test.go

@@ -26,3 +26,10 @@ func TestParsePath(t *testing.T) {
 		Wish(t, ParsePath(`0/\//2`).segments, ShouldEqual, []PathSegment{{s: "0"}, {s: `\`}, {s: "2"}})
 	})
 }
+
+func TestPathSegmentZeroValue(t *testing.T) {
+	Wish(t, PathSegment{}.String(), ShouldEqual, "0")
+	i, err := PathSegment{}.Index()
+	Wish(t, err, ShouldEqual, nil)
+	Wish(t, i, ShouldEqual, 0)
+}