FTS-2041: Make Optimizer standalone process

The merge request turns the Optimizer from a service inside the fts_server binary/daemon into its standalone fts_optimizer binary/daemon.

Implementation details
The same Server mechanism from fts3::server::Server is adopted and reused. The new Optimizer daemon starts with a main() function, which instantiates a new OptimizerServer. The OptimizerServer, in turn, starts the HeartBeat and Optimizer services, running them in their own thread, design consistent with all other services. The fts_optimizer binary runs 2 services for the moment, namely the HeartBeat and OptimizerService.

As the HeartBeat service needed to be reused, certain code refactoring was needed. Most importantly, the mechanism by which the HeartBeat service was observing critical threads and making sure they did not stop relied on global variables. As the new OptimizerServer was in a different binary altogether, it was decided to refactor this mechanism (FTS-2042).

Now each critical service will register itself with the HeartBeat service, including specifying a grace time period and a graceful abort function. The HeartBeat server will regularly iterate through all the registered critical services and ask them for their last run timepoint. It will then compare this timepoint with the current time, and if the difference is larger than the registered grace period, the graceful abort function is called.

In this refactoring, also the QoS daemon dropped its own HeartBeat (aging) implementation and will use the same one, provided by fts3::server::HeartBeat.

The new fts_optimizer binary is packaged in the fts-server PRM. Proper sysconfig and systemd files are provided as part of the RPM installation.

Changes are currently deployed on FTS3-Pilot.