Add option to make message type fields always nullable about krotodc

[Dogacel]

I prefer the current implementation. We have a convention of adding optional to every field explicitly. But generally, It makes more sense to generate all of them nullable by default, because this convention is just a thing we made up.

Also, if field is unset in the non-null implementation, are we seeing a NullPointerException in runtime?

We use https://github.com/bufbuild/protovalidate to ensure field nullability for example. I had a long conversation in pbandk issues. Ability to generate code as nullable or not nullable based on certain options. What do you think about this?

[mscheong01]

Also, if field is unset in the non-null implementation, are we seeing a NullPointerException in runtime?

No, these fields are set with default instances

[mscheong01]

I also agree that having an option for both is the best way to go.

[Dogacel]

Also, if field is unset in the non-null implementation, are we seeing a NullPointerException in runtime?

No, these fields are set with default instances

One reason why Proto uses unset as the default instance rather than null is recursion

message LinkedList {
  string value = 1;
  LinkedList next = 2;
}

In this case, the generated code shouldn't really work, right? I assume Kotlin code looks like this:

data class LinkedList(
  val value: String,
  val next: LinkedList,
)

Which is basically impossible to initialize. As long as code throws an appropriate error, I like it.

[Dogacel]

Sorry for late response, I am reproducing the bug here: #19

Because every message is optional by default, I expect to see this behavior time to time.