Set up reloading after_initialize

[composerinteralia]

Fixes #336

Before this commit, the initialization process looked like
this:

Rails runs all of the initializers

1. Run the "factory_bot.set_factory_paths" initializer
2. Run the "factory_bot.register_reloader" initializer, which sets up a prepare callback
3. Run the :run_prepare_callbacks initializer
4. This triggers the factory_bot prepare callback, which causes factory_bot to reload

Rails runs after_initialize callbacks

1. I18n initializes
2. factory_bot reloads again as described in Add back loading definitions in after_initialize #334

The double reloading of factory_bot in this initialization is not ideal,
but also shouldn't generally cause any problems on its own.

The problems people are having in #336 come from the fact that
I18n gets set up in an after_initialize callback, but factory_bot gets
reloaded before the after_initialize callbacks are triggered.
If the FactoryBot.define block references any code that uses I18n
translations as it loads, that code will raise an error (references
inside other factory_bot methods, or code that uses I18n translations
inside of methods still works fine, since the whole Rails initialization
process would be complete by the time any of that code runs).

This commit moves factory_bot reloading from a prepare callback into an
after_initialize callback. This allows us to avoid reloading
factory_bot before I18n is loaded, and also gets rid of that pesky
double reloading of factory_bot.

The new initialization process looks like:

Rails runs all of the initializers

1. Run the "factory_bot.set_factory_paths"
2. Run the :run_prepare_callbacks initializer, which no longer involves factory_bot

Rails runs after_intialize callbacks

1. I18n initializes
2. Run the factory_bot reloader, which sets up the prepare callback for
   any future prepares (for example calling reload! in the console), and
   executes the reloader to run the initial FactoryBot.reload

[composerinteralia]

I would like to get a failing test before merging this, but I had trouble making that happen.

!@y-yagi it would be great if you could take a look at this PR, if you have a moment. I seem to be playing Whac-A-Mole with the bugs related to this reloading feature. Failing a bunch of specs on CI. I will ping you again once I get all of that resolved.

[aledustet]

This is a more elegant solution that doesn't relly on double reloading, wonder if a test like the one on #347 would make sense?

[aledustet]

Is there anything we should include in the docs now there is not a config to be passed in?

[composerinteralia]

This class is not meant for public use, so changing the API should be fine.

[aledustet]

The way I understand this, the to_prepare block that was part of the config before now will be under the reloaders?

[composerinteralia]

In later versions of Rails this amounts to the same thing. config.to_prepare pushes the callbacks into an array which later gets copied over to app.reloader.to_prepare.

But it didn't work quite like this in Rails 4.2, which is why we are getting CI failures.

[composerinteralia]

I am going to close this for now. When we drop support for Rails 4.2 we can revisit this, and I agree we will definitely want to keep the test from #347.