MINIFICPP-2377 Support process group level controller services

[lordgamez]

• Controller services are only found if they are in the scope of the processor or controller that tries to get it (in the same process group or in a parent group)
• Tests are modified to use a single root ProcessGroup that contains the used processors and processor handles are only stored as raw pointers
• Processor start and shutdown is changed to avoid deadlock when a findProcessor call is running on the same process group

https://issues.apache.org/jira/browse/MINIFICPP-2377

---

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

For all changes:

• Is there a JIRA ticket associated with this PR? Is it referenced
  in the commit message?

• Does your PR title start with MINIFICPP-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

• Has your PR been rebased against the latest commit within the target branch (typically main)?

• Is your initial contribution a single, squashed commit?

For code changes:

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
• If applicable, have you updated the LICENSE file?
• If applicable, have you updated the NOTICE file?

For documentation related changes:

• Have you ensured that format looks appropriate for the output in which it is rendered?

Note:

Please ensure that once the PR is submitted, you check GitHub Actions CI results for build issues and submit an update to your PR as soon as possible.

[lordgamez]

This and similar changes in the startProcessingProcessors and startProcessing functions are to avoid deadlock. It appeared in ControllerServiceIntegrationTests when stop() is called while the getControllerService is called in the processor's onTrigger. The stop() function waits for the processor's onTrigger to finish, but it cannot finish the ProcessGroup's findProcessor method because it is waiting for the same mutex which is held here.

We may need to find a better solution as this may cause some concurrency issues I'm not currently aware of. I'm open for suggestions.