rpc: add ChainHash message with both bytes and string representations

[ffranr]

This is a follow up PR for this review comment: #1074 (comment)

This commit introduces the ChainHash RPC message, which contains two fields:

• A raw byte representation of the hash, ideal for direct use in Go RPC calls.
• A byte-reversed hexadecimal string representation of the hash, convenient for users who need to copy and paste the value, such as when passing it as a command-line argument.

[ffranr]

@guggero @Roasbeef, I'm wondering if there's a more general location where we can define this type of RPC message, so it can be utilized across all our RPC subpackages. Any ideas on that?

[coveralls]

Pull Request Test Coverage Report for Build 10403975668

Details

• 0 of 7 (0.0%) changed or added relevant lines in 1 file are covered.
• 10 unchanged lines in 5 files lost coverage.
• Overall coverage remained the same at 40.163%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
rpcserver.go	0	7	0.0%

Files with Coverage Reduction	New Missed Lines	%
rpcserver.go	1	0.0%
tapdb/addrs.go	2	79.04%
tappsbt/create.go	2	53.85%
asset/asset.go	2	81.54%
commitment/tap.go	3	84.7%

Totals
Change from base Build 10385622104:	0.0%
Covered Lines:	23684
Relevant Lines:	58970

---

💛 - Coveralls

[guggero]

While I like the idea, see my inline comment for why we might not want to do it.
But happy to be overruled...

[guggero]

LGTM 🎉

[jharveyb]

LGTM - wondering if we should swap this in in other relevant spots / RPC messages before the next major release?

Non-blocking.

[guggero]

LGTM - wondering if we should swap this in in other relevant spots / RPC messages before the next major release?

I think we don't want to change any APIs that have already been in a released version. So the field changed in this PR is the only one we can change without potentially breaking anyone's application.

But we should keep this in mind for future fields.