useorocos: Fix for recursive package dependencies within the same workspace

If Orocos package `package_c` depends on another Orocos package `package_b` and `package_b` depends on a non-Orocos package `package_a` (e.g. a catkin package) in the same workspace, there is currently no way to tell `package_c` to also use `package_a` without an explicit dependency:

```
package_a/CMakeLists.txt:
  project(package_a)
  catkin_package(
    INCLUDE_DIRS include
  )
```
```
package_b/CMakeLists.txt:
  project(package_b)
  orocos_generate_package(
    DEPENDS package_a
  )
```
```
package_c/CMakeLists.txt:
  project(package_c)
  orocos_use_package(package_b)
```

While the dependency between `package_a` and `package_b` will be correctly reflected in the `Requires:` section of the generated pkg-config file for  `package_b`, the export mechanism introduced in f0f44e619115883c5e624f2ae32ac6de61ddbc6f cannot "see" this dependency and `package_c` will not find the exported header files in `package_a/include`.

This patch adds recursive dependency traversal to `orocos_generate_package()`, required for packages built in the same workspace. The resulting behavior should be the same as if `package_c` would be built in another workspace, where the `package_a` libraries and include directories would also be added by the pkg-config call for `package_b`.

The other commit is a minor cleanup of the control flow in `orocos_find_package()` starting at [UseOROCOS-RTT-helpers.cmake:203](https://github.com/meyerj/rtt/commit/10eec82e2dd468030a7d3d9d6961c41e15fc9baf#diff-32e94bf0e0e0e2c3419f4c4e7b16ac4aR203) and not really related.