Support SM2 signature

[dongbeiouba]

Support SM2withSM3 signature.
Fix cgo CFLAGS and LDFLAGS, should set CGO_CFLAGS and CGO_LDFLAGS when build or test.
Change the file name of examples to main.go for simple.

[itomsawyer]

这里为啥要用结构体封装一层，而不是直接使用interface？
可以考虑 Privatekey 结构，自己实现 https://pkg.go.dev/crypto#Signer 接口，包括这个pkg中的sign等func。 这样在外部传递的时候可以只用interface 而不是 struct 实例传递。

这样在example 里也不需要出现类型强转（调用这个函数的用户视角）

[itomsawyer]

另外还需要考虑一下兼容性

https://pkg.go.dev/crypto#PrivateKey

[dongbeiouba]

已经有参考golang标准库接口，比如Pulibc()，但是没必要严格一致。

signer这东西里面有opts [SignerOpts]，先不打算支持，先确保基本功能可用，是否支持Equal()我认为并不重要，如果后续有需求可以再增加。

[dongbeiouba]

这里为啥要用结构体封装一层，而不是直接使用interface？ 可以考虑 Privatekey 结构，自己实现 https://pkg.go.dev/crypto#Signer 接口，包括这个pkg中的sign等func。 这样在外部传递的时候可以只用interface 而不是 struct 实例传递。

这样在example 里也不需要出现类型强转（调用这个函数的用户视角）

使用struct封装，而不直接使用底层的interface，是为了给模块增加特定实现，不同算法的特定实现不一样，比如sm2和rsa就不一样，可以给struct增加特定方法，而底层interface继续保持精简，上层模块可以按需实现。
golang crypto中各个模块也有类似的实现，可以参考一下https://pkg.go.dev/crypto/[email protected]#PrivateKey 、 https://pkg.go.dev/crypto/[email protected]#PrivateKey 等等。

[itomsawyer]

特定实现应该用struct 来实现接口，而不是struct 里面嵌套interface ，这样实际相当于没有格式检查的强转.
比如这里SM2PrivateKey 的入参不是sm2实现，该构造函数也不会提示任何错误。

crypto.LoadPrivateKeyFromPEM 返回的PrivateKey 已经对应一个具体实现了，所以我推荐这里格式校验一下.
https://pkg.go.dev/crypto/x509#example-ParsePKIXPublicKey

只不过golang通过struct 可以判断类型， 我们crypto.pKey本身也是一层封装，所以需要通过KeyType 来校验

[dongbeiouba]

删除了不优雅的SM2PrivateKey等类型转换，直接传入interface类型。

签名、验签时，增加SM2密钥类型判断。

[itomsawyer]

sign 和 verify 可以支持

priv.SignPKCS1v15 和 priv.VerifyPKCS1v15 这样调用吗？

[dongbeiouba]

和sign(priv, data)调用方式差别不大，可以先提供sm2.Sign() API满足基本功能。