Improve some code, fix some bugs

[CodePlayer]

What this PR does / why we need it?

Summary of your change

1. 基于 JDK 8 现有特性对齐代码，精简部分冗余代码（ 例如：使用 StringBuilder 替代 StringBuffer、使用 Class::method 简化 Lambda、减少不必要的拆箱/装箱 ）
2. 封装并复用部分方法，减少部分重复代码
3. 改进部分 Map集合 的迭代处理，例如：将 containsKey( key ) + get( key ) 简化为一次 get( key ) 调用（ 仅限 value 不为 null 的场景），containsKey( key ) + remove( key ) 简化为一次 remove( key ) 调用。
4. 修复 BUG [BUG] 单引号的原始值boolean无法解析进对象 #3283
5. 使用 String.replace() 替代 String.replaceAll()，避免不必要的正则表达式处理开销。
6. 改进 部分访问修饰符的可见性与一致性
7. 修正 潜在的条件分支错误，例如：com.alibaba.fastjson.util.TypeUtils#castToJavaBean(java.util.Map<java.lang.String,java.lang.Object>, java.lang.Class<T>, com.alibaba.fastjson.parser.ParserConfig) 和 com.alibaba.fastjson2_demo.Int2Decoder#acceptField。
8. 改进部分 集合类 的初始化容量，避免中途循环遍历的多次扩容开销。

Please indicate you've done the following:

• Made sure tests are passing and test coverage is added if needed.
• Made sure commit message follow the rule of Conventional Commits specification.
• Considered the docs impact and opened a new docs issue or PR with docs changes if needed.

[wenshao]

由于无法修复windows JDK 11下com.alibaba.fastjson2.fuzz.DeepTest.testObj的单测失败的问题，我先回滚了。

这些改进很好，但是否能否开PR来提交，一个commit修改太多不合适。

[CodePlayer]

由于无法修复windows JDK 11下com.alibaba.fastjson2.fuzz.DeepTest.testObj的单测失败的问题，我先回滚了。

这些改进很好，但是否能否开PR来提交，一个commit修改太多不合适。

这已经算是拆分开后的了，只有几十个文件，每个文件的改动也很小，除了个别封装方法的，大多数都只有一两行代码的改动。
另外还有不少 benchmark 和 单元测试相关的改动，就没并入这次提交了。

报错的那个，本地没法复现，看代码似乎是一个嵌套了 100000 层的 JSON，出现了 StackOverflowError，应该和具体环境的堆栈、内存参数设置有关。

[wenshao]

由于无法修复windows JDK 11下com.alibaba.fastjson2.fuzz.DeepTest.testObj的单测失败的问题，我先回滚了。
这些改进很好，但是否能否开PR来提交，一个commit修改太多不合适。

这已经算是拆分开后的了，只有几十个文件，每个文件的改动也很小，除了个别封装方法的，大多数都只有一两行代码的改动。 另外还有不少 benchmark 和 单元测试相关的改动，就没并入这次提交了。

报错的那个，本地没法复现，看代码似乎是一个嵌套了 100000 层的 JSON，出现了 StackOverflowError，应该和具体环境的堆栈、内存参数设置有关。

最初我也是这么想的，但我将100000降到1000也会同样的错误，并且找不到原因，我就只能回滚了。分开提交可以找到错误的原因。

[CodePlayer]

我数了一下，StackOverflowError 的溢出行数恰好是 1024，不过 Fastjson2 里面设置的是 2048（JDK 8 是 512），所以 JDK 超过 1024 就报错了。
我看了下 JDK 发行版，似乎是 Zulu 11.0.26-4 x64，而且是最新版本，我下载一个到本地看看是否与该JDK的最新设置有关。

[wenshao]

这里比较奇怪的点是，其他平台，其他JDK没有报错

[CodePlayer]

这里比较奇怪的点是，其他平台，其他JDK没有报错

问题已经找到了，我在自己的Fork项目中也开通了 Github Workflow，通过排除法，发现是 maven-surefire-plugin 插件加了下面这行配置的问题 ：

<argLine>-Dfile.encoding=UTF-8</argLine>

把这行配置去掉，再次执行就测试通过了……也是醉了……