修复 PostgreSQL jsonb 类型在模型类中的使用

[Yurunsoft]

fix #606

[codecov]

Codecov Report

Attention: 8 lines in your changes are missing coverage. Please review.

Comparison is base (fe052af) 61.42% compared to head (889a818) 65.46%.

Additional details and impacted files

@@             Coverage Diff              @@
##                2.1     #610      +/-   ##
============================================
+ Coverage     61.42%   65.46%   +4.03%     
- Complexity    11256    11257       +1     
============================================
  Files           893      896       +3     
  Lines         30668    30662       -6     
============================================
+ Hits          18837    20072    +1235     
+ Misses        11831    10590    -1241     

Files	Coverage Δ
src/Components/pgsql/src/Model/PgModel.php	88.00% <ø> (ø)
src/Model/Model.php	88.08% <100.00%> (+0.11%)	⬆️
src/Model/Traits/TJsonValue.php	94.44% <94.44%> (ø)
src/Model/Traits/TListValue.php	80.00% <80.00%> (ø)
src/Model/Traits/TSetValue.php	33.33% <33.33%> (ø)

... and 85 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[NHZEX]

后续迭代支持通用解析器的可能性：

• 考虑扩展成支持基于字段的自定义转换（目前的Json解析变为解析器的一个子实现）。
• 解析器支持覆盖指定类型或指定字段的转换。
• fieldParseNullTypes这个配置归属为解析器内的定义更合适。
• 可能会和目前的get、set访问方法定义会产生冲突或冗余？

[Yurunsoft]

后续迭代支持通用解析器的可能性：

• 考虑扩展成支持基于字段的自定义转换（目前的Json解析变为解析器的一个子实现）
• 解析器支持覆盖指定类型或指定字段的转换
• fieldParseNullTypes这个配置归属为解析器内的定义更合适

现在就支持覆盖指定类型的字段转换，建一个项目模型基类就可以。

这 3 个每个都会影响性能，这个 PR 的实现对性能影响最小。

如果希望自定义 Json 序列化字段值，也可以重写 jsonSerialize()。

目前来看，需要重写 Json 序列化字段值的场景并不是很多，不是很值得用性能去换低频场景的便利性。

[NHZEX]

现在就支持覆盖指定类型的字段转换，建一个项目模型基类就可以。
如果希望自定义 Json 序列化字段值，也可以重写 jsonSerialize()。

更倾向于注解或者配置方式定义，不太想动基类或者重写，可能会导致更改过于分散吧。

这 3 个每个都会影响性能，这个 PR 的实现对性能影响最小。

觉得这方面的性能损耗对比各种io是可以忽略的，模型对象本身是一个性能损耗高的地方，性能换取便利和安全，觉得问题不大。

目前来看，需要重写 Json 序列化字段值的场景并不是很多，不是很值得用性能去换低频场景的便利性。

对于重写方法或者基类来实现功能需求，觉得操作太重了，侵入性太强了，参差不齐的实现容易产生BC或者性能问题。有这个功能使用成本会低很多，才会有更多的场景去用么。

[Yurunsoft]

这样的话，考虑在Meta里预处理好配置数据，争取实际运行代码的位置加少量判断，减少性能损耗。

---

可能会和目前的get、set访问方法定义会产生冲突或冗余？

不会冲突，这个 PR 里增加的是从数据库查询结果实例化对象和保存到数据库之前的数据处理。

跟 getter、setter 方法完全没冲突。

打算在 3.0 还可以实现自定义 Json 序列化字段值处理，比如 bigint 转 string。