BVH - fix lockguards for multithread mode

[lawnjelly]

Due to an embarrassing lack of variable name, the BVH lock guards lifetimes previously did not cover the whole function call.

This is fixed, and the warning message for contention is removed as multithread mode seems to be desired in production in 4.x.

Fixes #73573

Notes

• BVH Multithread mode was added in BVH - thread safety option #48892 for debugging purposes in 3.x, and in classic case of creep this has ended up being used in production in 4.x.
• Due to the debugging nature, this was not highly tested, and it turns out I missed out the variable name and the lifetimes of the lock guard were only for the duration of the line, rather than the function (which is the aim of lock guard).
• Additionally, as multithread mode seems intended to be used in production in 4.x, the warning message is removed.
• There could also potentially be lock guards used for the supplemental functions:

	uint32_t item_get_tree_id(BVHHandle p_handle) const { return _get_extra(p_handle).tree_id; }
	T *item_get_userdata(BVHHandle p_handle) const { return _get_extra(p_handle).userdata; }
	int item_get_subindex(BVHHandle p_handle) const { return _get_extra(p_handle).subindex; }

These weren't added originally because this was intended to be non-production code. I will try and investigate whether these are necessary to prevent any potential race conditions, but that can be a separate PR if necessary.

[RandomShaper]

Loving C++ as much as you do.

[bitsawer]

Interestingly, Facebook had to crate special C++ linter rules to detect just this kind of bugs especially with RAII scope and mutex guards, so it's a pretty common mistake to make. https://youtu.be/lkgszkPnV8g?t=1939 (This comes up around 32:19 mark and some discussion about it before that).

[akien-mga]

Thanks!