remove the crc-32 library from dependency

[Danil42Russia]

Issue

Closes #1437.

The table was generated in advance, via:

function main() {
  const POLYNOMIAL = -306674912;
  for (let i = 0; i < 256; i++) {
    let r = i;
    for (let bit = 8; bit > 0; --bit) {
      r = ((r & 1) ? ((r >>> 1) ^ POLYNOMIAL) : (r >>> 1));
    }

    console.log(("0x" + (r >>> 0).toString(16)).padStart(8, "0"))
  }
}

If you need to write tests, I'll add them

Checklist

• I have updated CHANGELOG.md
• I have run all the tests locally and no test failure was reported
• I have run the linter, formatter and spellchecker
• I did not do unrelated and/or undiscussed refactorings

[verytactical]

Please don't add generated code here.

[Danil42Russia]

Why?

1. it is faster than creating a table every time;
2. it is done by analogy with crc16, which has the same table.

[verytactical]

Which of the two options sounds more correct? :)

• execute 2048 operations every time compiler starts
• have a table of questionable provenance that is impossible to review, that also takes 65536 operations every time TS checks types, and also increases size of js bundle

[Danil42Russia]

So typescript and type checking is called only once, when building a project. And if you don't calculate the table, you will have to do it every time you start the compiler.

Regarding the “weird” table:

1. This table is available in the LLVM project: https://github.com/llvm/llvm-project/blob/6383a12e3b4339fa4743bb97da4d51dea6d2e2ea/llvm/lib/Support/CRC.cpp#L30
2. There are many references in Microsoft repository https://github.com/search?q=org%3Amicrosoft%20%220xD9D65ADC%22&type=code

If you look at the code of the js-crc32 library, it doesn't get any better, it doesn't even have comments https://github.com/SheetJS/js-crc32/blob/master/crc32c.js#L85

[Danil42Russia]

To make sure the table is correct, you can copy from anywhere else, diff will be zero.
I can also add its generator to the project.

[verytactical]

I realize there are quite a few mentions of this table online, because it's used for something like last half of a century, but I don't think checking numbers by hand is a sound approach to development.

type checking is called only once

There's also tsserver.

[verytactical]

The original issue started specifically with

Write tests with a contract that uses crc32 function that pass strings with unicode characters.

Until there are tests for unicode characters, or rather any crc32 tests at all, we can't even know that hash is computed the way it did before, and can't do any of these changes.

[verytactical]

Imagine worst-case scenario: we have something like message(crc32()) in tact contract, gets evaluated at compile-time as constant expression, all the contract tests pass because bindings use precisely the same value, then incorrect contract is deployed.

[verytactical]

If src/optimizer/interpreter.ts is the only place we call it from, we never pass Buffer here.

Buffer is Node's non-standard API for binary data, while there is platform-agnostic Blob. When we build browser version of @tact-lang/compiler, we have to include a polyfill for Buffer.

While there are other places that use Buffer, we're working hard to remove them. I'd consider removing Buffer support here too.