Add command line utility to query a node

[ralexstokes]

it would be handy for debugging, etc. to have a command line utility that is just a thin wrapper over the various API methods:

$ beacon-api-client --endpoint http://NODE_URL node version $ beacon-api-client --endpoint http://NODE_URL beacon header latest

to start, the endpoints that take data can just accept json on the command line as well (think curl) but in the future there could be some way to pass SSZ (either via file or hex-encoded string...)

[ralexstokes]

ralexstokes/beacon-api-client#65 is relevant

[ralexstokes]

a skeleton for the CLI functionality was added in ralexstokes/beacon-api-client#65.

we can improve the skeleton a bit further before we get to the stage where we can just implement all of the endpoints.

one thing we can do is consider the return values and/or how the CLI returns information to the user

if we refer to this line https://github.com/ralexstokes/beacon-api-client/blob/a6fe869c49f13b6ad6ff768af5fa8d35f158fa28/src/cli/mod.rs#L9

we see:

1. the println! call in each method implementation
2. basic error handling with .unwrap

we can reduce a lot of code (and make this function a bit more flexible) by just returning the results of each Client call and to paper over the different types, we can return the trait object Box<dyn std::fmt::Debug> and just have every action of run_cli return something like Box::new(object) where object is the return data from the particular call of that action. if we do this, then in main we can just dbg! the return data

here is an example of this trait object thing, for reference https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=000613b1be9b4098a0fd25a17e3b6c02

to address (2), we can return the top-level Error used in the Client from run_cli, so run_cli's return type would become something like Box<dyn fmt::Debug, Error>

[ralexstokes]

after we lay a foundation following the previous comment, we can start to sketch out the rest of the functionality of each of the client methods

I would suggest starting with a smaller namespace like Node or Debug and seeing how that shapes up

alternatively, it would be smart to start w/ the methods that are most likely to cause problems to make sure approach favored by the foundation makes sense

some things to prototype:

1. GET vs POST methods
2. it would be nice to leverage serde_json or something to parse the args for each Namespace method, as the simple thing will be to just take strings from the clap parsing; and then we need to bridge the gap from the stringly-typed data to the strongly-typed data required by the Client