"Nullable" annotation support

[vaind]

FlatBuffers supports omitting a field - this is evaluated by ObjectBox as if the field had NULL value. Currently, the generated C/C++ code always expects values to be present.

To bring compatibility with other language bindings as well as extend functionality :

• the FBS schema parser should support a nullable annotation
• the generated C/C++ code should handle missing values gracefully when reading.
• open question - what about writing - should we generate pointer-based code (as in Go)? Or go with "default value" (usually zero) as Flatbuffers do?

[greenrobot]

What's the current behavior? I think when reading a non-present field from FB e.g. into an int the resulting value should be the the default (zero).

Hmm, nullable... Would like to avoid that (first annotation specific to generator(?)), but I guess we don't have much choice? 🤔 To make things worse, there might be multiple options, e.g. raw pointer, std::unique_ptr and std::optional.

PS.: std::optional represents the FB behavior best. And, if we decide to add an annotation, I see "optional" are a more fitting name.

PSS.: In Java, there are some locations, where you have to provide a "null value". E.g. imagine an annotation on the fbs like "null-value: -1"; reading from FB without a value would result in an int value -1 (and vice versa). I'm not saying that this is the best idea ever, just to throw in some brainstorming here....

[vaind]

We could also make use of .fbs field "default" value being explicitly specified to mean the field is nullable and should be stored as null if its value equals to the default... Then the generated store/load code would behave pretty much like standard flatbuffers.