message names not camel-cased

[lestrrat]

I thought I fixed this, but

definitions:
   foo_bar:
      ...

produces a message like

message Foo_bar  {
...
}

[lestrrat]

I guess I never fixed this, as fixtures had the same problem. fixed in #77

[lestrrat]

Argh, this was not fixed in its entirety.
The definition (message Foo { .. }) had been fixed, but the associated return values are still problematic.

I'm going to file a fix, but at the end of the day what we probably need is a type registry of sorts, so we don't have to do this everywhere that we must refer to these types

[lestrrat]

Oh boy, I found something else (don't know the root cause yet).

If you don't mind, I'm going to make the following changes so it's easier to narrow down the problem:

1. Remove all uses of os.Exit and log.Fatal
2. Make most functions/methods return an error

This is because I'm getting a an empty line where I expect some sort of string to be present, and to get to the bottom of it, I need to get errors all the way from the bottom of the call stack