load gmul table from disk

[FullyRobert]

pr #45 and issues #37 both mention that loading gmul_table from disk is an elegant way. In this pr, I modify the g_table function, introduced Serde crate to serialize the table, and store it in the file gmul_table. When the gmul function needs to use g_table, it can easily load the file and deserialize it as a table struct.

Benchmark tests have found that the performance improvement of the gmul function using the load approach is not significant (about 2-5%), probably because a large number of gmul operations amortizes the precomputed gtable time. In any case, loading gtable from the hard disk is effective in reducing warming time, and the loading time is nearly zero( 300mb/s for serde deserialize procedure)

Hope my code can be well-reviewed, and I will add more commit to implement it.

Test result:

test sm2::ecc::internal_benches::bench_gmul ... bench: 50,762 ns/iter (+/- 791) test sm2::ecc::internal_benches::bench_gmul_load ... bench: 48,357 ns/iter (+/- 1,143)

[FullyRobert]

a clippy error found in error.rs never occurred before, but I never modify this part of code

[Pencil-Yao]

感谢你对libsm的代码贡献，原谅我的迟到，以及用中文进行回复： 首先我想说将预算值以数据的形式（当前模式），亦或者代码的形式（我也有过尝试），还有运行时的形式（当前状态）来讲，我得出的结论是： 代码的形式 > 数据的形式 > 运行时的形式 然而优势过于微小，并且仅适用于CLI工具的形式，对于一个更常规的持续运行的服务来说，3者的差别仅仅是cache load方式的不同。对于这个优化的建议我认为我是有点不负责任的，或者说我应该由自己去实现。

从最后的结果来看，收效也是甚微的，所以我的决定是close这次的pr，当然你可以与我在这里进行交流

[FullyRobert]

感谢您的回复，您的考虑非常有道理，我决定不再提交关于预计算缓存的有关内容。

不过此pr中有一个移除旧版本g_mul函数 #45 的提交，在之前的pr中为了比较优化预计算的结果我保留了该函数，现在将其移除应当是合理的，我应当重新发起新的pr么