Add non scalar default support to BFBS files

[jtdavis777]

This PR adds in an extra field to the reflection.fbs that holds string representations of non scalar defaults -- vectors and strings, specifically.

This isn't the 'best' way to accomplish this, but I think its the most pragmatic given how prolific the Value struct is in the code base.

Accepting suggestions for better names!

[jtdavis777]

@dbaileychess and @aardappel interested to hear your collective take on this one! I realized this was missing while working on the wireshark generator.

[aardappel]

This PR has formatting and other changes that appear not directly related that make it hard to review.

Why is the new bool in Value needed? Doesn't the Type already tell you if it is scalar or not?

[jtdavis777]

This is getting at the inelegance of the design -- much of the code relies on the constant string being default constructed as "0". Pair that with std::string not being able to differentiate between empty and unset and you end up either needing to do a large refactor, or pull some shenanigans like this.

I tried to just default construct constant and set it to 0 if a scalar type, but then I couldn't tell the difference between "user set default to "" and no default. Which is probably okay? But with all of the modifications needed to go that route it seemed wrong. I can try that again if the bfbs doesn't need to tell the difference between set to empty and unset, maybe I tried too many things at once.

[jtdavis777]

in reading up on the non scalar defaults more (#6053), it does seem that the bfbs would need to differentiate between being provided a default ( = "") and not being provided one (nullptr) -- std::string doesn't have a mechanism to differentiate this, so I'm left with

1. adding a boolean (implemented here)
2. wrapping the constant member in some sort of std::optional-esque thing (which I did try, it got messy real fast)
3. injecting and removing an extra set of "" when a non scalar default is provided (so that .empty()) would mean nothing provided and """" would be equivalent to "" which would be set in the bfbs

1 or 3 would work for me, and I can work to remove the auto formatting to make the pr easier to review (vscode format go brrrrrr)

[jtdavis777]

there were only two lines of formatting changes -- the other change is flatc now generates scoped enums instead of unscoped.

[aardappel]

@dbaileychess your review here would be helpful

[jtdavis777]

not 100% ready for merge but want to get it into the review pipeline

[dbaileychess]

I feel like a better long term solution is to have a default_value field that is of type Union (long, string, short, etc..)

[jtdavis777]

Would you want me to deprecate the old constant field to do so?

[jtdavis777]

This would also have to be a union of struct of primitive, since unions of primitives aren't a thing

[aardappel]

Probably not great to remove the existing fields.. so we may as well continue with the current pattern?

Just not great to merge strings and vectors into 1 field. Better probably to have default:string (which at least in FlatBuffers can be detected as not-set vs empty) and default_vector:bool` ?

In terms of the variable constant in the parser.. I actually like your idea of making it contain the string including extra "": this would make a lot of sense as way to represent different types of values inside a string.

The long term solution would be to replace constant with a variant<int64_t,double,string,bool> or similar? But that will likely cause a LOT of code churn.

[jtdavis777]

I will see about refactoring this to use option 3