unittest mock improvement and reusability.

Is your enhancement proposal related to a problem? Please describe. The #52894 PR cleaned up the Bluetooth controller unit test significantly by introducing uut and mocks library.

However, it still has sub-optimal code like this: https://github.com/zephyrproject-rtos/zephyr/blob/802eabf43f01b72aef615d48b0f08c05a0f32392/tests/bluetooth/controller/ctrl_feature_exchange/CMakeLists.txt#L11-L12 https://github.com/zephyrproject-rtos/zephyr/blob/802eabf43f01b72aef615d48b0f08c05a0f32392/tests/bluetooth/controller/uut/CMakeLists.txt#L38

Preferable CMake code which creates libraries should be included in the most straight forward way possible, following the folder structure of the repo.

As mocks may be reusable between test suites, then it should be considered how such sharing can be obtained, and the need for add_subdirectory() from the toplevel CMakeLists.txt test file is not needed.

Describe the solution you'd like Idea: create common location where CMakeLists.txt are sourced in an heriachy and shared CMake libraries can be created. Two options:

Always source the tree and define the libraries. The actual library to use will depend on link library calls in top-level CMakeLists.txt file. This cleans up the top-level CMakeLists.txt file, but might have reduced build performance.
Add extra arguments to COMPONENTS unittest, so that the extra CMake tree is sourced based on knowledge provided by top-level CMakeLists file, for example a call like:
```
find_package(Zephyr COMPONENTS unittest bluetooth-uut bluetooth-mock HINTS $ENV{ZEPHYR_BASE})
```
This approach allows to only source required components. It requires more knowledge by the user writing the test, but no build time penalty.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context

zephyrproject-rtos / zephyr

unittest mock improvement and reusability. #53741