Shenandoah: Fix evac OOM scoping for concurrent class unloading

CI threw up a bunch of asserts claiming that OOM scope hasn't been set-up correctly on an evacuating code path. I believe I have tracked this down to ShenandoahUnlinkTask calling into runtime and coming back with a native LRB call that is not procted with OOM scope. See stacktrace below:

Stack: [0x00007f3d40dcb000,0x00007f3d40ecb000], sp=0x00007f3d40ec9900, free space=1018k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x134b1c4] ShenandoahHeap::evacuate_object(oop, Thread*)+0x4f4
V [libjvm.so+0x153a4b2] ShenandoahBarrierSet::load_reference_barrier_impl(oop)+0x242
V [libjvm.so+0x153a893] ShenandoahBarrierSet::load_reference_barrier_not_null(oop)+0x73
V [libjvm.so+0x153e9b6] oop ShenandoahBarrierSet::load_reference_barrier_native_impl<oop>(oop, oop*)+0x86
V [libjvm.so+0x153b2d4] ShenandoahBarrierSet::load_reference_barrier_native(oop, oop*)+0x34
V [libjvm.so+0x92a7e6] AccessInternal::PostRuntimeDispatch<ShenandoahBarrierSet::AccessBarrier<1187956ul, ShenandoahBarrierSet>, (AccessInternal::BarrierType)2, 1187956ul>::oop_access_barrier(void*)+0x96
V [libjvm.so+0x9266d6] ClassLoaderData::is_alive() const+0x36
V [libjvm.so+0x13266c4] nmethod::flush_dependencies(bool)+0x204
V [libjvm.so+0x1561aa0] ShenandoahNMethodUnlinkClosure::do_nmethod(nmethod*)+0x80
V [libjvm.so+0x15e5b46] ShenandoahConcurrentNMethodIterator::nmethods_do(NMethodClosure*)+0xa6
V [libjvm.so+0x15619bb] ShenandoahUnlinkTask::work(unsigned int)+0x2b
V [libjvm.so+0x18bc0c6] GangWorker::run_task(WorkData)+0x66
V [libjvm.so+0x18bc1b8] GangWorker::loop()+0x48
V [libjvm.so+0x17980bb] Thread::call_run()+0xfb
V [libjvm.so+0x13b64a9] thread_native_entry(Thread*)+0x119