Proposal: Add initfalse and optionaldefault options for dataclass generation

[oaimtiaz]

I’m working on a project that uses SQLAlchemy with MappedAsDataclass, and I’ve been using sqlacodegen to generate the model layer. First, thank you for the amazing tool, it's saved me a lot of time on the boilerplate!

As someone relatively new to open source contributions, I’m still getting comfortable with the process. That said, I’ve made a local branch with a couple of options that would help my use case, and I’d love feedback on whether it would be worthwile/broadly useful to open a PR to bring these options into the tool.

Rationale

When using MappedAsDataclass, the models output by sqlacodegen would require all columns and relationships to be defined when constructing a new record before inserting. This can be pretty verbose, and, in most cases, these values are going to be left as-is. These options would allow a slightly different pattern: server defaults or optional columns can be omitted at construction time, and specified explicitly.

Proposal

I’d like to propose adding the following two options for the DataclassGenerator:

1. initfalse:
   This option would set init=False on relationships and columns with server_default values. This allows models to be instantiated without specifying values that are expected to be managed by the DB or ORM.
   This could probably be fleshed out to have more comprehensive coverage.
2. optionalDefault:
   This option would set default=None for columns that are optional. Again, this would reduce the repetitive boilerplate when constructing new instances.

I'm not sure if these options are too niche to my use-case, so I'd appreciate any thoughts on if this is useful, or if it needs any refinement before opening a PR.

Thanks again!

[sheinbergon]

@oaimtiaz thank you for your proposal. While it could be relevant, what scarace resources currently available are directed towards increasing type compability and feature coverage, fixing bugs and improvingt he overall user expiernance for maintstream databases.

I believe your suggestion might be related to #248 so it's definitly something worth looking at, but there are a few issues we'd like to take a stab at before tackling this one