For users who don't use config.async, sending events is currently a blocking operation. This means a request won't complete before some SDK operations like serializing or making requests to Sentry are also finished. So this PR introduces non-blocking event sending functionality to the SDK.

The functionality works like this:

1. When the SDK is initialized, a Sentry::BackgroundWorker will be initialized too.
2. When an event is passed to Client#capture_event, instead of sending it directly with Client#send_event, we'll let the worker do it.
3. The worker will have a number of threads. And one of the idle threads will pick the job and call Client#send_event.

• If all the threads are busy, new jobs will be put into a queue, which has a limit of 30.
• If the queue size is exceeded, new events will be dropped.

About Sentry::BackgroundWorker

• The worker is built on top of the concurrent-ruby gem's ThreadPoolExecutor, which is also used by Rails ActiveJob's async adapter. This should minimize the risk of messing up client applications with our own thread pool implementation.
• It respects users' async implementation. So if the users have config.async set, the worker won't initialize a thread pool and won't be used either.
• The worker will be initialized at the end of the Sentry.init call.

New Configuration Option - background_worker_threads

This change also introduces a new background_worker_threads config option. It allows users to decide how many threads should the worker hold. By default, the value will be the number of the processors the user's machine has. For example, if the user's machine has 4 processors, the value would be 4.

Of course, users can always override the value to fit their use cases, like

config.background_worker_threads = 5 # the worker will have 5 threads for sending events

Users can also disable this new non-blocking behaviour by giving a 0 value:

config.background_worker_threads = 0 # all events will be sent synchronously

closes #1130