Fix mismatched protobuf service param location

This PR fixes a bug which can arise when the name of a parameter is lowercase in a service definition. The bug arises when the field name of a message is lowercase in the .proto definition and it's specified to be in a custom location in the HTTP options of a service definition. Example:

syntax = "proto3";
package TEST;
import "github.com/metaverse/truss/deftree/googlethirdparty/annotations.proto";

message MsgA {
  int64 A = 1;
}
message Thing {
  MsgA a = 1;
}
service Map {
  rpc GetThing (Thing) returns (Thing) {
    option (google.api.http) = {
      get: "/1"
      body: "a"
    };
  }
}

When truss is run against this file, it issues the following warning:

WARN[0000] GetThing.A is a non-base type specified to be located at 'query', outside of the body. Non-base types outside the body may result in generated code which fails to compile.

This warning shouldn't exist, as the parameter is specified to be in the body of the request. The bug arose because the name of the type was CamelCased in the generated Go code but not in the protobuf definition, so when they where compared, they'd be missed and would default to being put in the query. To fix this, the names from the protobuf definition are CamelCased before they're compared.

metaverse / truss

Fix mismatched protobuf service param location #271