Feat: initial contracts folder setup, registry structs

[hstove]

• Closes Clarity Registry Contract Setup #112

Description

This PR introduces the contracts folder, which is where sBTC Clarity contracts and contract unit tests will be located.

Within that folder is the start of the sbtc-registry contract, which is where data structures for deposits and withdrawals will live. This PR implements the data structures for withdrawals, along with a function and tests for writing new withdrawal requests.

Note that this does not implement the user-facing initiate-withdrawal-request contract function. Instead, this is only an "internal" function for storing the necessary data.

The unit tests are located in ./contracts/tests/sbtc-registry.test.ts.

PNPM workspace

This also introduces a PNPM workspace, which allows for efficiently installing and managing multiple folders that include JS packages. It also allows easily running a command multiple workspace packages at once (such as pnpm test -r to run test in each package).

Type of Change

• New feature

Does this introduce a breaking change?

List the APIs or describe the functionality that this PR breaks.
Workarounds for or expected timeline for deprecation

Are documentation updates required?

• Link to documentation updates:
  • Top-level README for installing contract-related dependencies
  • Contracts folder README for setup and testing instructions related to contracts

Testing information

• Tests can be performed by running pnpm test in the contracts folder.

Checklist

• Code is commented where needed
• Unit test coverage for new or modified code paths
• pnpm test passes
• Changelog is updated
• Tag 1 of @person1 or @Person2

[setzeus]

Not entirely too familiar with the the Clarigen/PNPM setup so don't have much feedback on anything except for the actual contract kickoff.

Only one question I have on an event emitted, once answered / updated we should be good to get this kickoff merge in!

[AshtonStephens]

A note on this template, @hstove I assumed this template was from the stacks-core repo for which most of the template didn't apply; do you think we should be filling out the PR template description the way it asks?

[hstove]

@AshtonStephens I'm not quite sure what you mean - that we should or shouldn't use this template? Or that this PR doesn't follow the template well enough?

[hstove]

Added print event and related tests in c669e3f

[setzeus]

LGTM! Kudos on the setup.

[AshtonStephens]

@AshtonStephens I'm not quite sure what you mean - that we should or shouldn't use this template? Or that this PR doesn't follow the template well enough?

I'm just asking you if we want to, but I'm not suggesting either way.

[hstove]

@AshtonStephens I found the template to be pretty helpful - I didn't follow it to the tee, but most of it seemed pretty applicable. That's partly because, for example, this PR actually needs testing instructions, but in the future we'll know how to test (and they'll be in CI). There are some things to probably remove (ie "tag X and Y"), but otherwise I like it.

In general, I think templates are overall helpful, as long as they don't have to be 100% matched 100% of the time.