CryptoContext->Eval... Tracing Framework

[AlexanderViand]

Adds a tracing framework that is essentially zero-cost when disabled at compile time (-DENABLE_TRACER=OFF) and extremely low-cost when enabled (-DENABLE_TRACER=ON) but not being used (see NullTracer and NullFunctionTracer).
The framework is extremely flexible in terms of what kind of tracing it allows.

A basic example is provided in the form of example-tracer.h (run example example-tracing with tracing enabled to see an example trace or see this gist).

However, the real power of the system is probably more apparent by looking at the HeraclesTracer from IntelLabs/encrypted-computing-sdk.

The framework consists of three components:

1. Tracing callbacks in all hierarchies of the Evaluator API (e.g. CryptoContext::EvalAdd, LeveledSHE::EvalAdd, RNSCKKS::EvalAdd, etc) register what function is being called, along with its inputs and outputs.
2. The main Tracer class (or, rather, a non-abstract derived class) is designed to keep track of global (where "global" here means "relative to a specific CryptoContext") state and is in charge of starting FunctionTracer instances when requested by the tracing callbacks.
3. Each FunctionTracer is responsible for collecting information about the specific function it was created for. In order to facilitate this, it has (read) access (by reference/shared_ptr) to the actual inputs provided to the traced function. This means that each tracing implementation is entirely free in how (or even if) it chooses to track data flows.

While the old tracing system tried to use raw memory addresses as identifiers, and an early iteration of this new system tried to keep track of object constructors/assignments, the current version of the framework does not actually prescribe any specific approach. However, it is strongly suggested to use the approach used by SimpleTracer, which hashes the serialization of an object to arrive at a unique id. In order to improve human readability, instead of using the raw hashes as identifiers, there is a little abstraction layer that assigns human-readable unique ids of the form ciphertext_1, ciphertext_2, plaintext_1, etc.

[AlexanderViand]

I've rebased everything to OpenFHE v1.4, and addressed a first set of review comments from @fdiasmor