Merge CodeBlock constant pools

[HalidOdat]

This PR merges the literals, names, functions, compile_environments constant pools into one constant pool called constants

[github-actions]

Test262 conformance changes

Test result	main count	PR count	difference
Total	95,609	95,609	0
Passed	75,978	75,978	0
Ignored	18,872	18,872	0
Failed	759	759	0
Panics	0	0	0
Conformance	79.47%	79.47%	0.00%

[codecov]

Codecov Report

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

Comparison is base (4a55990) 45.64% compared to head (a2a8472) 45.40%.
Report is 8 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3413      +/-   ##
==========================================
- Coverage   45.64%   45.40%   -0.24%     
==========================================
  Files         483      483              
  Lines       49517    49790     +273     
==========================================
+ Hits        22600    22609       +9     
- Misses      26917    27181     +264     

Files	Coverage Δ
boa_engine/src/bytecompiler/env.rs	100.00% <100.00%> (ø)
boa_engine/src/environments/runtime/mod.rs	75.96% <ø> (ø)
boa_engine/src/object/internal_methods/function.rs	91.17% <100.00%> (+0.56%)	⬆️
boa_engine/src/vm/mod.rs	56.37% <ø> (ø)
boa_engine/src/vm/opcode/define/own_property.rs	77.08% <100.00%> (ø)
boa_engine/src/vm/opcode/delete/mod.rs	64.15% <100.00%> (+1.40%)	⬆️
boa_engine/src/vm/opcode/get/property.rs	76.27% <100.00%> (+0.83%)	⬆️
boa_engine/src/vm/opcode/push/literal.rs	69.44% <100.00%> (+4.92%)	⬆️
boa_engine/src/vm/opcode/set/property.rs	63.54% <100.00%> (+1.17%)	⬆️
boa_engine/src/bytecompiler/mod.rs	66.79% <93.33%> (-0.13%)	⬇️
... and 18 more

... and 26 files with indirect coverage changes

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

[nekevss]

Overall, this looks pretty good to me. Just had one thing regarding docs.

Definitely interested to see the new codeblock trace! 😄

[nekevss]

Can there be Panic docs added to these functions so they pass future lints.

Also, a little nitpicky aside, I don't dislike naming the functions as _expect. I do think it's clear, but would it be worthwhile being more explicit with _or_panic? I'm fine with either/or but wanted to at least mention it.

[HalidOdat]

Maybe we should remove the postfix? I only added it because we have .resolve_expect() and .environment_expect() to be consistent with the naming. But there isn't a rust guideline neither does the std lib do this.

[jedel1043]

+1 to the suggestion about removing the suffix. It's not common for Rust APIs to name panicking functions with a suffix. It's much more common to panic by default, then offer try_* variants for non-panicking functions.

[nekevss]

Yeah, I was sort of thinking about the try_* naming convention when I was looking at it. It's much more common for us to return a JsResult throughout the engine as a default. So instead of adding try_* everywhere, adding some sort of naming convention on the panicking functions in our case might be a bit better clarity-wise.

That being said, sticking to the typical naming convention and removing the suffix is also a valid option.

[raskad]

Look good. I only have one very minor suggestion.

[nekevss]

This looks good to me 😄 Thanks for adding the panic docs!