Introduce read-write lock for code reloading; do code reloading before controller name resolution

[leonid-shevtsov]

What? Why?

• Fixes https://github.com/bigcommerce/gruf/issues/174 (at least, for us)
• Zeitwerk suggests using a read-write lock for code reloading, so that reloading cannot happen during a parallel request.
• Moved code reloading to happen before the controller is constantized, because otherwise you get a stale class and it doesn't work with reloading included modules.
• Or, rather, now it wraps the entire service method call, first reloads the code if necessary, then locks for read access
• In production mode the write lock will never be acquired, and the read lock will simply let code through.

How was it tested?

• Added tests, plus errors described in #174 went away on my machine.

[leonid-shevtsov]

Not sure what i should do with the rubocop & codeclimate errors; i could refactor ServiceBinder, but it seems like the issue has been there before my changes. Rubocop issues are old as well.

[leonid-shevtsov]

Updated to bypass locking mechanism

[splittingred]

@leonid-shevtsov Thanks! https://github.com/bigcommerce/gruf/pull/181 should fix the rubocop issue. (Edit: this has been merged now, can you rebase?) - Also, can you update CHANGELOG.md with a description of the changes?

[leonid-shevtsov]

Sorry, got back from the break. All done. Pleased to resolve my own rubocop warnings.