spec: use official proto wrappers for primitive fields

[jdef]

• updated spec uses official protobuf wrapper types
• updated golang build file mangles path for wrappers.proto
• fixes Wrapping OPTIONAL fields in proto3. #22

[jdef]

I'm not very happy w/ the Makefile updates. I couldn't think of a better way to manage the path to wrappers.proto. It doesn't make sense to include the path to the golang version of wrappers in the official spec because the official spec should be language neutral. Looking at the standard version of wrappers.proto that ships w/ protoc, it's clear that the golang package for file is expected to live in the golang/protobuf tree. Furthermore, when NOT doing the mangle step the go get ... step fails because the official google/protobuf repo doesn't have any golang files in src/google/protobuf (where the upstream wrappers.proto lives).

Suggestions welcome

[jdef]

I should add, there's also the possibility of vendoring the wrappers.proto file that we're using, and then referring to the vendored copy. We're not vendoring anything yet, so I'm hesitant to open that can of worms simply for this change set.

[jdef]

The OOB feedback that I've received so far is that these changes are too aggressive: only the OPTIONAL fields should use the wrapper types.

[jdef]

Received additional OOB feedback that the consistency w/ respect to has_xxx funcs (in C++, for example) is good as-is.

[jdef]

Discussed in the CSI WG meeting, determined that default values are "good enough" signals and that we simply need stronger language in the spec regarding the use of defaults to serve as signals for unspecified fields. The wrappers can be useful but are a bit unwieldy to deal with, depending on the programming language of the generated code.