feat!: crate split and rename

[nickysn]

The crate runtime_tracing was split into several new crates:

codetracer_trace_types - contains the types, used in the trace file
codetracer_trace_reader - library for reading trace files
codetracer_trace_writer - library for writing trace files
codetracer_trace_capnp - helpers and common types for the Cap'n'proto binary format (version 0 binary format)
codetracer_trace_cbor_zstd - helpers and common types for the CBOR+ZSTD binary format (version 1 binary format)

Additionally, the runtime_tracing_cli utility has been renamed codetracer_trace_util. The original runtime_tracing crate has been deleted. Projects that use runtime_tracing should be updated to use either codetracer_trace_reader or codetracer_trace_writer (or both, if necessary) and codetracer_trace_types. Compilation errors are expected to be easy to fix, mostly by changing the use statements. All the names of the types, functions and traits are the same, they are just moved around into different crates and modules.

Reasons for these changes:

• We will be able to maintain separate, independent APIs for the writer and the reader. This will allow us to change the reader API quickly, to accomodate the DB backend rewrite, without the need to update the writers and all the language tracer modules (which only need the writer, not the reader).
• The new crate names include CodeTracer in their name, making it more clear what these packages are all about.
• Since most users of these libraries will only need the reader, or only the writer, this will bring less unused code into their projects.

[alehander92]

is it a problem that we define this enum twice: if we import both libraries somewhere ( i assume there is not a good central place to put it into)

[nickysn]

I'd like to have separate enums for the reader and the writer. The fact that the enum was shared before lead to hacks, such as specifying BinaryV0 and BinaryV1 separately, which makes sense for the writer (which can write both versions of the format), but not for the reader (which detects the binary format version from the file header, and handles BinaryV0 and BinaryV1 the same). The question is whether they should have the same name (in different modules), or different. Also, I still haven't unified BinaryV0 and BinaryV1 for the reader, but it can be done, as soon as this PR is merged. And it will not break the writer API, which is one of the goals of this PR - being able to update the reader API, without changing the writer API.

[alehander92]

ok, but if they are different at some points, then we would need to be able to easily reasonably map the one enum to the other one: I assume that would be easy for us as maintainers of the libraries, and for the users , probably the documentation would clarify any questions

[nickysn]

I'll think of some way to map them to each other, or at least, map them to some structure of strings like ID and description - for easy implementation of GUI/TUI, because that's what we actually need. But I'm planning to do this in a future PR.

[alehander92]

looks good: still think we might find a prelude lib useful, but we can decide on that later, when trying to upgrade runtime_tracing libs in db-backend?