Ensure that we allocate from the correct bucket when using engine specific storage

As of MB-49071, we allow more complex objects to be stored in the engine specific. We should be able to assert that we only call the get/storeEngineSpecific methods on ep-engine with ObjectRegistry::getCurrentEngine() == this (ep-engine). 

Unfortunately, a bunch of tests fail when we do that.

123 - ep-engine_ep_unit_tests.NotifyTest (Failed)

242 - ep-engine_ep_unit_tests.PersistentAndEphemeral/StreamTest (Failed)

252 - ep-engine_ep_unit_tests.PersistentAndEphemeral/DcpStreamSyncReplTest (Failed)

253 - ep-engine_ep_unit_tests.Persistent/DcpStreamSyncReplPersistentTest (Failed)

255 - ep-engine_ep_unit_tests.PersistentAndEphemeral/ConnectionTest (Failed)

322 - ep-engine_ep_unit_tests.RangeScanValueScan/RangeScanTest (Failed)

323 - ep-engine_ep_unit_tests.RangeScanKeyScan/RangeScanTest (Failed)

324 - ep-engine_ep_unit_tests.RangeScanTestSimpleKeyScan/RangeScanTestSimple (Failed)

417 - memcached_testapp.folly.default.TransportProtocols/InterfacesTest (Failed)

This is at least in part because all (most?) public ep-engine methods reset the currentEngine to nullptr on exit. See the implementations of acquireEngine and EPHandle. 

This causes certain paths to not have the correct currentEngine set. See for example https://github.com/couchbase/kv_engine/blob/master/engines/ep/tests/module_tests/collections/evp_store_durability_collections_dcp_test.cc where we call into VBucket after calling some ep-engine method. 

Possible solutions

1) We could "fix" EPHandle to capture the current engine and reset it on ~EPEngine, but not sure the overhead is worth it as this should not matter in production.

2) We could add a BucketAllocationGuard around all relevant call sites.

Notes

Suggest boost::backtrace to help in finding where we fail.