Allow more flexibility in the code generation

[spacekitteh]

Several things I think would greatly benefit the experience of using this package, particularly when you don't control the .protos.

1. Allow specification of various field properties. One example is whether to unbox/unpack a field in numerical applications; another is the type, such as specifying a newtype. Another might be to declare "although this says optional, it isn't really, so don't bother with the Maybe" - e.g., for well-defined mathematical constructs such as vectors.

2. Generalising this, allow specifying the entire data structure for a specific message, as well as encoding/decoding functions. For example, if I am being sent a 500x500 matrix as a bytestring, I might want to store it as a sparse matrix, and not construct the intermediate data structure.

3. Control naming. For example, I might prefer to have vec'someRepeatedField not have the vec in front.

[blackgnezdo]

@spacekitteh there's a tension between increasing the amount of features and focusing the library on doing one thing. I believe proto-lens should remain solely focused on translating values between Haskell and byte streams. The protocol buffer feature set is necessarily limited to the subset expressible in a large number of programming languages. Haskell can represent a much richer set of invariants about its data. I don't believe we can meaningfully extract the features that are "the most important" and implement just these.

So, while it may be annoying and repetitive, our own use of protocol buffers often contains a translation to application internal representation immediately at proto-lens boundary.