Update worker docs and change default worker mode.

[BWStearns]

Highlight worker mode settings in the worker page.

Also should the default worker mode be BackgroundAsync? The path of least surprise for a background job running tool is that it runs jobs in the background, and the suggested cargo loco start run command doesn't result in an instance that will actually run the jobs.

[jondot]

Thanks for the docs fix.

For workers default mode and path of least surprise -- Loco is all about nailing down the path of least surprise.

I think, that because Rust is multithreaded, etc. for development using BlockingAsync -- you are completely right. If we go that way, when a user goes to production, they will need to move to Redis and proper background. I'm wondering how many users will make a mistake and never make this move in production because they're not educated to do it. What do you think?

(meanwhile I'm merging this PR, thanks!)

[BWStearns]

I think it's convenient to have BackgroundAsync as the default because it's the least setup to get developing. Maybe there could be a warning printed out on startup explaining that prod probably wants to use BackgroundQueue?

Additionally I was wondering about adding a capability to name the queues when you're using BackgroundQueue so that digging around Redis with the cli or RedisInsight could be more informative.