feat: Basic metrics client

[zkknuckle]

The main idea is that the traces will be written to file when the SP1_LOG_PATH env var is set. The metrics crate can then be run separately to process the logs and digest the profiling information.
This approach has two main pros:

1. It enables a developer working on the metrics crate to iterate faster as they do not have to re-run the test updates to their log ingestion code
2. The codebase does not have to change at all to incorporate a metrics client. We can keep the existing traces and ingest those instead of writing our own custom timings. Custom metrics may also start to bring unforeseen challenges in the future such as additional flags, threading state between objects, etc.

To test set the SP1_LOG_PATH env var to a file for which the tracing crate will write logs.

Run the following:

RUST_LOG=debug cargo test stark::machine::tests::test_fibonacci_prove --release -- --nocapture

And then inside of the new metrics crate simply run:

cargo run

Example output:

The metrics binary still does pretty primitive checks against the tracing span strings.
Open work to b done:

1. It should be decided how to best set the spans so that if they are changed either in the client or the metrics crate that running the metrics crate does not break. We probably need some sort of constants inside of core that set tracing log spans.
2. We could refactor the metrics crate to form a log graph. Right now the parent span is tracked individually and compared against to calculate percentages. Ideally we could build a graph as we parse the logs, process the graph in one step (calculating percentages/total times), and then display any charts based upon the processed graph.