Consider improving error messaging / stacktrace on failing workers when strict mode is enabled

Currently, binding a Worker that fails in onStart gives a cryptic stacktrace when StrictMode is enabled:

   throwable = java.lang.IllegalStateException: android.os.strictmode.DiskReadViolation
at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1658)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:250)
at java.io.File.isDirectory(File.java:843)
at java.io.File.toURI(File.java:728)
at libcore.io.ClassPathURLStreamHandler.<init>(ClassPathURLStreamHandler.java:51)
at dalvik.system.DexPathList$Element.maybeInit(DexPathList.java:750)
at dalvik.system.DexPathList$Element.findResource(DexPathList.java:777)
at dalvik.system.DexPathList.findResources(DexPathList.java:572)
at dalvik.system.BaseDexClassLoader.findResources(BaseDexClassLoader.java:330)
at java.lang.ClassLoader.getResources(ClassLoader.java:839)
at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:349)
at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:402)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:488)
at kotlin.sequences.SequencesKt___SequencesKt.toCollection(_Sequences.kt:787)
at kotlin.sequences.SequencesKt___SequencesKt.toMutableList(_Sequences.kt:817)
at kotlin.sequences.SequencesKt___SequencesKt.toList(_Sequences.kt:808)
at kotlinx.coroutines.CoroutineExceptionHandlerImplKt.<clinit>(CoroutineExceptionHandlerImpl.kt:23)
at kotlinx.coroutines.CoroutineExceptionHandlerImplKt.handleCoroutineExceptionImpl(CoroutineExceptionHandlerImpl.kt:46)
at kotlinx.coroutines.CoroutineExceptionHandlerKt.handleCoroutineException(CoroutineExceptionHandler.kt:33)
at kotlinx.coroutines.StandaloneCoroutine.handleJobException(Builders.common.kt:196)
at kotlinx.coroutines.JobSupport.finalizeFinishingState(JobSupport.kt:229)
at kotlinx.coroutines.JobSupport.tryMakeCompletingSlowPath(JobSupport.kt:906)
at kotlinx.coroutines.JobSupport.tryMakeCompleting(JobSupport.kt:863)
at kotlinx.coroutines.JobSupport.makeCompletingOnce$kotlinx_coroutines_core(JobSupport.kt:828)
at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:100)
at kotlinx.coroutines.intrinsics.UndispatchedKt.startCoroutineUndispatched(Undispatched.kt:193)
at kotlinx.coroutines.CoroutineStart.invoke(CoroutineStart.kt:112)
at kotlinx.coroutines.AbstractCoroutine.start(AbstractCoroutine.kt:126)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.launch(Builders.common.kt:56)
at kotlinx.coroutines.BuildersKt.launch(Unknown Source:1)
at com.uber.rib.core.WorkerBinderKt.bind(WorkerBinder.kt:329)
at com.uber.rib.core.WorkerBinderKt.access$bind(WorkerBinder.kt:1)
at com.uber.rib.core.WorkerBinder.bind(WorkerBinder.kt:80)
at com.uber.rib.core.WorkerBinder.bind$default(WorkerBinder.kt:75)
at com.uber.rib.core.WorkerBinder.bind(Unknown Source:14)

It seems worker is failing and exception is bubbling up to JVM exception handler, and to fetch that there is IO in ServiceLoader.

The failure path is visible in WorkerBinder.kt at bind lines 75, 80, and 329; start by tracing how an onStart exception reaches the JVM handler when StrictMode is enabled, including the ServiceLoader lookup shown in the stacktrace. Done means the worker failure produces a useful error message or stacktrace instead of the cryptic StrictMode trace.