refactor(kclvm-runner): encapsulate dylib generating, linking and executing in kclvm/lib.rs into kclvm-runner

[zong-zhe]

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

• N
• Y

fix #67 and #82

2. What is the scope of this PR (e.g. component or file name):

kclvm-runner/runner.rs
kclvm-runner/lib.rs

3. Provide a description of the PR(e.g. more details, effects, motivations or doc link):

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Other

1. Encapsulate dylibs generating and executing in kclvm/lib.rs into kclvm-runner.
2. Add struct "KclvmAssembler" in kclvm-runner/runner.rs to provide method "gen_libs" for dynamic link library generating.
3. Add struct "KclvmLinker" in kclvm-runner/runner.rs to provide method "link_all_dylibs" for dynamic link library linking.
4. Add method "execute" in kclvm-runner/lib.rs to encapsulate dylibs generating(gen_libs), dynamic link library linking(link_all_libs) and running(runner.run) together.
5. The main purpose of separating the three parts from kclvm/lib.rs and encapsulating them into kclvm-runner is to support reuse in kcl-vet.
6. Decoupling the assembler and llvm.
7. The assembling LLVM IR into a dynamic link library is encapsulated into "LlvmLibAssembler" separately.
8. Add trait "LibAssembler" to describe the interface "KclvmLibAssembler" should have. If other intermediate code is added in the future, the corresponding assembler must implement this trait.
9. Struct "LlvmLibAssembler" is provided in "KclvmLibAssembler". "KclvmLibAssembler" is an enum that implements trait "LibAssembler". "KclvmLibAssembler" is responsible for the compilation of a single kcl file in one thread.
10. "KclvmAssembler" is responsible for the concurrent compilation of multiple kcl files.
11. "KclvmAssembler" will call the method in "KclvmLibAssembler" to generate a dynamic link library for a single kcl file in each thread of concurrent compilation.

4. Are there any breaking changes?(Y/N) and describe the breaking changes(e.g. more details, motivations or doc link):

• N
• Y

5. Are there test cases for these changes?(Y/N) select and add more details, references or doc links:

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• Other

Add test cases in kclvm-runner/src/tests.rs and kclvm-runner/test_datas.
Add bench in kclvm-runner/benches/bench_runner.rs

Benchmark stats

1. KCL Test Case

// kclvm/runner/src/test_datas/init_check_order_0/main.k
schema Person:
    name: str
    age: int
    gender: str
    info: str = "{}, {}, {} years old".format(name, gender, age)

alice = Person {
    "name": "alice",
    "age": 10,
    "gender": "female"
}

2. Bench Stats (Compare with before refactoring)

2.1 CLI Report

2.2 HTML Report

6. Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[ldxdl]

Pls put benchmark stats into the PR info.

[ldxdl]

As a refactor PR, it would be good to have some preparation for future backend target abstractions.

[ldxdl]

Do not hardcode 'dylib' in all naming. In fact, it may be .ddl, .dylib, .so on different platforms. I prefer to change all 'dylib's to 'lib's.

[ldxdl]

This refactoring should preferably do some preparation for the subsequent target abstraction refactoring. For example, dylib and llvm were all hardcoded as the only impl way, you may need to change them into variables first, and then the next refactoring will replace these variables through traits or other dynamic methods to make it a target abstraction with a set of impls. At the same time, do not hardcode implementation keywords like 'dylib', 'llvm' in the comments and docstrings.

[Peefy]

You'd better lint code by using cargo clippy in the runner crate.

[Peefy]

LGTM

[chai2010]

LGTM

[Peefy]

LGTM