Moved the feature prereq checks to run after the setting has been locked...

This one is good to go

@johnsimons this is slightly different from what we discussed but I realized that the main issue is that prereqs is checked to early. I now moved them to run after settings has been locked. I still see the potential need to have the setup to return false to allow for a final chance to abort but I think that can be a separate pull and I argue that we can keep the prereqs as is since they now seem to be correct?

This change highlighted an issue that I don't see a fix for. Since prereqs can only be checked when settings are locked and defaults only can be executed as long as settings are NOT locked. This means that there is always a chance that the feature decides to not go ahead with the setup and in that case defaults would remain applied. I argue that we have to leave it this way since the order seems to be correct and that we need to avoid code that assumes those defaults to be in place. Ie only code in the setup of the feature it self can assume default to be there.

Thoughts?

(I've ignored the test that checks for this - https://github.com/Particular/NServiceBus/commit/94d70b7f33d9137cf46012048a7855754b169f65#diff-79016c895ef1d7bb88e05108cbae5a8bR45)

Potential fix for #2277