Improve Skip Builds Handling on Build CLI & Disable TLS Initial on Jemalloc

[AmmarAbouZor]

This PR closes #2152

Build CLI Tool:

This PR improves tracking the state of the last build to determine which builds can be skipped by:

• Additional features will be included in the persists build records for the last running job alongside with Checksum of the files for the given target.
• Use serde to write and parse the file instead of the manually implementation previously, enabling adding more information to the build state without having to change the parse code.
• Use one file for development and production by saving this information in the code itself instead of having to files for each build since we will keep one of them at a time anyway.
• Updating the integration tests for the CLI tool to accommodate the new changes.

Jemalloc Memory Allocator:

This PR disable initial allocating TLS memory because it leads to Chipmunk exceeding the allowed TLS memory for a process on Linux machine when it run combined with NodeJS and Electron

[DmitryAstafyev]

Bellow in code you are getting access to BuildStateRecords as a ref

 pub fn get(production: bool) -> anyhow::Result<&'static BuildStateRecords> {
        static CHECKSUM_RECORDS: OnceLock<anyhow::Result<BuildStateRecords>> = OnceLock::new();

        CHECKSUM_RECORDS
            .get_or_init(|| BuildStateRecords::load(production))
            .as_ref()
            .map_err(|err| anyhow!("{err}"))
    }

All looks good, but it's still a little bit weird. You are wrapping items into Mutex to have mut access to a list, all good. But what it in some time letter you will need some new member in BuildStateRecords, which also would need mut access?

Would it make the solution more scalable, if in OnceLock you will create not an instance of BuildStateRecords, but Mutex<BuildStateRecords>. In this case, you would not need to wrap items into Mutex and you will be able to get access to &mut BuildStateRecords from everywhere. Besides that, you BuildStateRecords can be easily extended with a new field, if it will be needed. Also good alternative might be RwLock if not all calls of BuildStateRecords require mut.

[DmitryAstafyev]

@AmmarAbouZor to me looks good and can be merged.. "green" light to do it. I've left only one comment and leave it to your responsibility. Realization of BuildStateRecords, looks good, but not scalable. Suggested changes will not change how the solution works, but can make it just more scalable. Maybe only one thing... If you never going to extend BuildStateRecords, probably makes sense to declare it as TupleStruct BuildStateRecords(BuildStateItems) to make it more transparent for a developer.

[AmmarAbouZor]

Very thanks @DmitryAstafyev for pointing out the issue with internal Mutex. At the start I thought that we could have other fields which doesn't need to be wrapped within the Mutex, but it ended up with more complex code. I moved the Mutex to outside of the struct itself.
This change won't remove the as_ref() call because this call is to avoid wrapping the Mutex within an Arc since we always need a reference of the records.

[DmitryAstafyev]

@AmmarAbouZor thanks for the corrections. Let it go! You are able to merge it as well