deployer: cleanup and unify CORBA deployers and fix shutdown and error reporting

[meyerj]

This pull request is a collection of three functionally independent older commits, but they are all related to the deployer executables and its variants cdeployer and deployer-corba and would cause merge conflicts if applied in arbitrary order.

kick out all components before shutdown and destroying the ORB

• Makes sure that shutdownDeployment() is called and the DeploymentComponent is destroyed before the call to ShutdownOrb() and DestroyOrb(). This allows the components to communicate with remote peers during their stop and cleanup transitions and to cleanly disconnect all connections.
• GitHub has a hard time to format this patch correctly in normal view because indentation changed for large parts of the file. In fact, only very few lines were changed, see https://github.com/orocos-toolchain/ocl/commit/6f2496a4872f550d374cf83c05672ddb2ce9ee43?w=1.

fixed OCL::Logging cleanup in deployer-corba

• lots of minor updates to unify the three deployer implementations, with only minimal functional changes
• cleanup of the OCL::Logging hierarchy as added in 12e97bea for deployer.cpp, in 2eae90e5 for cdeployer.cpp, but was missing in deployer-corba.cpp
• catch CORBA errors in cdeployer, like with deployer-corba
• Actually the implementation of the executables in bin/ would deserve another major refactoring because they still contain a lot of duplicated code and a way too long main function.
• Again, best viewed with https://github.com/orocos-toolchain/ocl/commit/6d10d0977e8d6a29d68bcdf24811acd4f271f466?w=1 because of changed indentation.

fixed error reporting of deployers if multiple config/script files are given in the command line

• fixes a regression from https://github.com/orocos-toolchain/ocl/commit/ae3cb626c76513c1308548d43f790a669e784836#diff-c65fdb7d93a41cd9995e883385187bd0L166, which broke reporting of errors in the exit status or check-only deployments as introduced in https://github.com/orocos-toolchain/ocl/commit/8107483d901868fe38f3f3cb0541a6bbde3780ad if more than one file is given in the command line
• f482b2b89adc722b577586fe4de120883fc91895 also partially resolved this issue by aborting the loop if one of the files could not be started/run successfully, but the deployer still does not exit immediately and runs the task browser instead. Is this the behavior that we want?