refactor: remove trin-utils dependency in ethportal-api

[njgheorghita]

What was wrong?

We can't release another ethportal-api version as long as it has a dependency on trin-utils

How was it fixed?

Extracted relevant "version" utils into ethportal-api

To-Do

• Clean up commit history and use conventional commits.

[KolbyML]

[carver]

The version of trin shows up incorrectly now:

cargo run -p trin -- --version
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/trin --version`
trin 0.3.0-6a02ed9f linux-x86_64 rustc1.81.0

(I guess this should be in a test, that the retrieved version for the CLI matches the trin crate version)

Potential solutions that seem suboptimal:

• publish trin-utils
• bind the version of ethportal-api and trin, to always release in lockstep (lots of problems with this. would we jump trin forward?)
• make build_info look outside of the ethportal-api crate (maybe not possible? even if it is, probably not what we want anyway)

The best alternative I can see:
Remove any dependency inside ethportal-api on the current version of trin, and move the build info back to trin-utils (Requires some research. What do we give up by not setting the version in the #command macro on TrinConfig ?)

Without this decoupling the version from ethportal-api, then the reported version in trin will depend on ethportal-api's build. Which is weird and probably wrong too often.