Setting `config.seed` before was fine because it only affected ordering, which happens after everything is loaded up and all the configure blocks have been run. Now, the seed is much more significant.

As this branch stands, `srand` is called from the beginning of `RSpec::Core::CommandLine#run` and empirical evidence indicates that code at the beginning of `CommandLine#run` is executed prior to `spec_helper.rb` getting loaded, which is the desired behavior, in my opinion because it allows a developer to call `srand` in `spec_helper.rb` and have it do what they would expect (i.e. seed randomization across the entire test run).

Regardless of strategy, the seed should be locked/frozen/etc as soon as we call `srand` because changing it after the fact only means that the user has no way to reproduce the randomization within the test run because RSpec will report the new value as the seed instead of what was actually used.

Also, RSpec documentation already discourages people from setting `config.seed` and points them to setting it via the command line using `--seed` as it should only be set for debugging a specific problem anyway.

Having the call to `srand` happen prior to developer code is essential in my mind because it supports the principle of least surprise. I expect, as an application developer, that calling `srand(123)` will seed randomization with 123 from that point on. If RSpec calls `srand` after `spec_helper.rb` is loaded, that completely invalidates calls to `srand` from spec_helper.