Add the daemon module and the standalone CLI for it

[ivanlele]

One of the PRs in a series addressing issue #28.

This PR introduces a daemon module that exposes a JSON-RPC handler, along with a new binary to start it. To avoid adding a new set of dependencies into the existing binary, a separate daemon feature flag was added.

The daemon can run either as an independent service or be embedded as a library and spawned as a separate thread within another process.

[ivanlele]

At first I planned to use https://crates.io/crates/jsonrpc, but it turned out to be client-side only. Extending it for server use would require adding several missing features. Other crates on crates.io have similar limitations, or are unnecessarily verbose.

Given that the JSON-RPC spec is quite small, I decided to implement a lightweight solution tailored to both our client and server use cases.

[apoelstra]

ACK 69f5664; successfully ran local tests
Had a previous, longer review but was lost in iteration on local CI setup.

[apoelstra]

Sorry for the noise. I think the "previous, longer review" text was not supposed to be posted publicly, which in turn is confusing my "did you already post this review" logic.

Edit Ah, no, it's that my vibe-coded duplicate-detection logic completely fails to handle newlines.

[apoelstra]

...on that one I forgot to rebuild the runner.

[ivanlele]

I would like to send some funny gif :D

[apoelstra]

Approval with same message already posted for PR #39

Phew, okay, it's working now.

The last two were caused by a shell quoting issue, and because I had "if a command fails when checking for dupes, just assume there weren't any" logic. I fixed both.

[apoelstra]

@ivanlele this PR changes the version from 0.1 to 0.2. Do you want me to cut a new release right after merging?

I think we might as well. In these early stages we should cut releases often.

[ivanlele]

@ivanlele this PR changes the version from 0.1 to 0.2. Do you want me to cut a new release right after merging?

I think we might as well. In these early stages we should cut releases often.

I believe we already have 0.2, so perhaps the next release should be 0.3 unless I'm missing something? And I agree, we can roll out a new realease, there are a few more approved PRs in the queue that would make a new release even more meaningful

[apoelstra]

Oh, interesting, this PR doesn't do the release, but because it's based on 0.1 while master is on 0.2 my git refs are out of date both of the crossed-out reasons, my release-detection logic thinks that it's a release PR. So never mind me.

Let me fix that logic and then I'll just merge this.