Create basic scaffolding for bridge core impl

[Rajil1213]

Description

This PR adds a very basic project structure (crates, crate-docs) for the bridge-core implementation. The traits will be added via another PR to issue #169.

As part of this PR, all the binaries have been moved to the bin/ directory as per the cargo package layout convention.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.

Related Issues

Closes #168 #169

[codecov]

The author of this PR, Rajil1213, is not an activated member of this organization on Codecov.
Please activate this user on Codecov to display this PR comment.
Coverage data is still being uploaded to Codecov.io for purposes of overall coverage calculations.
Please don't hesitate to email us at [email protected] with any questions.

[delbonis]

Most of these crates don't really have a purpose being created until we actually have something to put in there. To me creating scaffolding should involve at least going as far as types and traits in trying to work out how the components will go together, leaving the specifics incomplete like I did creating all the chain/state types in the state crate and stuff. What bridge-exec and bridge-rpc-service will actually look like is completely unspecified because not only are the details unspecified, but the components they interface with are also still mostly unimplemented as of this PR.

I think right now we should just be focusing on (1) doing the transaction assembly and (2) pulling in work from the alpen_ RPC interface. Let's wait until we move the tickets into JIRA to define more concrete bridge impl tasks.

Also I would be reorganizing the binary crates shouldn't be done in a PR like this, it's breaking changes with other PRs so we should avoid bundling it with new stuff. I still don't really like that structure.

[Rajil1213]

@delbonis I agree on all the points you've raised. As discussed in the DMs, this PR is more about getting your feedback on the overall project structure before I start writing out the traits. The issue #169 for this was created some time ago.

For the bin refactor, I think that is ultimately the right step given the more "official" convention but yeah, it probably shouldn't be part of this PR as it stands right now. For the time being, I am converting this PR back to a draft and will start working on the trait implementation. After I write out some stubs for the operator/challenger binaries, I think moving the sequencer/reth binaries inside bin/ might make more sense.

[Rajil1213]

Closing this PR to prevent wasteful CI runs and will create a new PR once the core traits are written out.