feat: allow parsing Bitcoin deposit memo with inscription and add E2E test for parsing

[bitSmiley]

Description

Adding e2e test for detecting memo from inscription.

The current btcutil does not have enough tapscript support, in this case, a nodejs sidecar to handle inscription txn generation is used instead. This is not intrusive and can be quickly removed once btcutil is upgraded.

How Has This Been Tested?

• Tested CCTX in localnet
• Tested in development environment
• Go unit tests
• Go integration tests
• Tested via GitHub Actions

Summary by CodeRabbit

• New Features

  • Introduced a logging feature to enhance visibility of test executions.
  • Added a test case for extracting Bitcoin inscription memo names.
  • Implemented an Express.js server with endpoints for Bitcoin transaction handling.
  • Developed a ScriptBuilder for constructing tapscripts used in Bitcoin transactions.
  • Created a utility function for formatting public keys in Bitcoin transactions.

• Bug Fixes

  • Improved transaction processing by updating methods to include witness data for better validation.

• Documentation

  • Added configuration files like tsconfig.json for TypeScript setup.

• Chores

  • Updated Docker configurations to include a new Bitcoin sidecar service in the setup.

[lumtis]

It seems it breaks the deposit BTC test: https://github.com/zeta-chain/node/actions/runs/10471358149/job/28998509065

Is the change supposed to be backward compatible

[bitSmiley]

@lumtis No, it should be backward compatible. There is an error fixed in b341832, which if OP_RETURN and inscription both cannot find the memo, then it should just return nil not error.

[lumtis]

@lumtis No, it should be backward compatible. There is an error fixed in b341832, which if OP_RETURN and inscription both cannot find the memo, then it should just return nil not error.

Ok, rerunning

[bitSmiley]

@lumtis sorry man, I just fixed the linting and change log, please help run the pipeline again.

[lumtis]

Opening back for develop for the next release

[lumtis]

Closing in favor of #2957 as discussed on Slack