Add table-specific configuration

[amilligan]

Hey Chad, I've been working with some legacy projects which present unusual requirements for fixture_builder (e.g. in some cases I need more than one table for the same domain concept, and the naming is somewhat all over the place). I made some minor configuration enhancements here that allow the user to specify the model class and output file for a particular table.

So, for example, if you have the wibbles table, but you want the associated model class to be Legacy::Foo and the fixture file to be 'legacy/foos' this will allow you to do that with the following:

FixtureBuilder.configure do |fbuilder|
  ...
  fbuilder.configure_tables(wibbles: { file: "legacy/foos", class: Legacy::Foo })
  ...
end

Incidentally, I use FixtureBuilder pretty regularly and I'm happy to help with maintenance, if you need. I'd like to ensure that it survives, because it's damn useful.

[thewoolleyman]

Hey @amilligan ! It would be great if you want to help out. I just haven't been using this in any of my active projects, so I haven't been motivated enough to hack on it myself.

That doesn't detract from the fact that I agree Fixture Builder is awesome, and I'd like to see it stay maintained and be used on more projects.

@rdy and I already had tried to reach out to another active forks about ownership, and got some initial interest, but then no follow up.

At this point, I think the best path forward is to transfer this repo from @rdy 's namespace and into its own organization: https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository

Then we can have multiple owners (including you), and start applying some of the PRs and publishing new gem versions from that repo.

If you're down with that, @rdy, I can try to do the up-front work to create a new organization and prep for the transfer.

[amilligan]

@thewoolleyman That sounds like a good plan to me.