Create an tbf parsing crate

[mihai-negru]

Pull Request Overview

The idea of this pull request is to set the foundation for building a rust version of tockloader. The arguments for this are:

• pip is not very portable when it comes to installing commands, it sometimes works just with pip, otherwise it needs pip --user or sudo.
• unifying the tools and libraries used for tock, so that we do not use two programming languages

Created a new workspace

• Workspace at the root level
• Two containing members elf2tab and tbfparser

Modifications in the elf2tab

• Removed the header.rs file and added to a new created crate
• Removed the utils.rs file because it can be found at the tbfparser library
• Modified Cargo.toml dependencies by adding the new created crate, the path is specified relative to the root project folder.
• Replaced the header file to tbfparser package.

Creating the new library crate tbfparser

• Created a library cargo crate.
• Moved header.rs to the lib.rs.
• Copied utils.rs in the src folder of the current crate.

Testing Strategy

This pull request was tested by compiling.
Copiled the project in the workspace using cargo build, resulting in elf2tab elf file.

TODO or Help Wanted

N/A

Documentation Updated

Added a new subsubsection in the elf2tabDetails to describe the project's structure. (workflow)

[alexandruradovici]

I second this approach, we have a lot of issues when installing tockloader.

[hudson-ayers]

One thing I think we did not address on the call today was whether we want to merge this before there is a working version of tockloader written in Rust -- @bradjc thoughts? This is pretty much just path renaming so it doesn't seem like it would really be an inconvenience, but I haven't developed much in elf2tab so want to make sure I am not missing something.

[hudson-ayers]

This looks fine to me, but will wait for Brad to make final decision about merging

[bradjc]

I'm fairly opposed to moving files around and having elf2tab/elf2tab/src.

At the risk of contradicting what I said on the call, I think if this is a push towards unifying code we should first look at moving the TBF code from this repo into tock/libraries/tock-tbf. That crate has a better namespace, and that way we don't still have two copies of all of the types. However, because tock-tbf is intended to be used in the kernel and with no-std, it might make not be possible to combine the two. In that case, having a dedicated tbf repo might make sense.