Add an error to go-runtime/compile when local Go identifier casing differs from FTL

[alecthomas]

Currently it's possible for a symbol to have two different casings within an FTL system - the native casing and the normalised FTL casing. We normalise casing across all languages to lowerCamelCase for fields and values, and UpperCamelCase for all types.

For example, if you have the following Go type:

type UserID struct {
  Name string
  ID string
}

This will be case-transformed to:

data UserId {
  name String
  id String
}

We should raise an error in this case.

[wesbillman]

@alecthomas the team had some questions around this in standup and we wanted to make sure we understand the issue we're trying to solve here. Do you mind clarifying what behavior you want to error on?

I was guessing it was the case where you write time.go with a UserID and it would then have this different casing in the schema as UserId and perhaps even generate echo.go with UserId, which would then have different casing between 2 go modules.

Thanks!

[alecthomas]

That's exactly right. In the owning module time.go the casing would be UserID but in all consumers the casing would beUserId, which would be confusing.