Simplify table config fetching logic

[Wulf]

Currently, we have a GenerationConfig#table(name) method that retreives the config for a particular table. This should be a simple retrieval, but instead, we make some changes to the table config before returning it. Let's move this to a pre-generation step in the beginning of lib.rs#generate_files.

Related comment here.

[hasezoey]

i was not sure what that function is meant to do, but i guessed by the usage and current code that it basically is:

a function to get a new instance of a table by name, and apply defaults again

then we should likely refactor this to actually be just a retrieval and generate all the tables in the beginning, but actually change it so that no new instance is created everytime and defaults applied (that us up to the user adding to that hashmap, right?)

i also wanted to refactor TableOptions itself to not use Options anymore and just use Default and remove the merger function (apply_defaults) and let it be up to the user

PS: i updated your link because the previous one was seemingly broken (likely because i rebased?)

[Wulf]

^ agreed. Two goals we should have for v3:

• refactor the config options, including TableOptions to be more ergonomic for end users
• reduce complexity in how we process/use the generation config / table options (like this issue)