Sorted testcases by nullability.

For nullable types, we have a Nullable[T], so I wonder if it makes sense to use Nullables or pointers. I see that someone added nullable support to maps via the pointer type, so this would be similar to that, while we use the Nullable wrapper in other cases. I don't like that we have two ways of doing this. It's too late now, though.

Once you rebase and CI runs, this should be submittable.

Regarding, Nullable[T], it may be useful for isolated values, allowing to distinguish the tri-state, but there is still the need to represent regular slices and maps where bi-state suffices and requires no overhead, allowing to make use of generated models in regular go code, where mutability of slice/map elements may be desired, which may be the case even during request/response construction.

This appears to cause a regression - rootlyhq/rootly-go#41 is now receiving i.e.

 type Alert struct {
        // AlertFieldValuesAttributes Custom alert field values to create with the alert
-       AlertFieldValuesAttributes []struct {
+       AlertFieldValuesAttributes []*struct {

When using prefers-skip-optional-pointer

As discussed in #2240, this wasn't actually an issue for Rootly's API

However, I don't know if this behaviour is correct when using the nullable.Nullable type?

Edit: I've raised #2242