Update feature flags to specific feature flag

[nekevss]

This Pull Request addresses the feature flag discussion from #3277.

It changes the following:

• Adds a temporal and promise-resolvers feature flag
• Sets experimental to be dependent on the feature flags

[github-actions]

Test262 conformance changes

Test result	main count	PR count	difference
Total	95,574	95,574	0
Passed	75,341	75,341	0
Ignored	19,482	19,482	0
Failed	751	751	0
Panics	0	0	0
Conformance	78.83%	78.83%	0.00%

[HalidOdat]

Looks good to me! :)

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (d281988) 47.10% compared to head (f13d464) 46.05%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3376      +/-   ##
==========================================
- Coverage   47.10%   46.05%   -1.05%     
==========================================
  Files         474      474              
  Lines       48737    48737              
==========================================
- Hits        22956    22448     -508     
- Misses      25781    26289     +508     

Files	Coverage Δ
boa_ast/src/lib.rs	75.00% <ø> (ø)
boa_engine/src/bigint.rs	65.71% <ø> (ø)
boa_engine/src/builtins/mod.rs	92.70% <ø> (ø)
boa_engine/src/builtins/temporal/mod.rs	26.78% <ø> (ø)
boa_engine/src/context/intrinsics.rs	97.54% <ø> (ø)
boa_engine/src/object/jsobject.rs	49.25% <ø> (ø)
boa_engine/src/object/mod.rs	29.04% <ø> (ø)

... and 8 files with indirect coverage changes

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

[jedel1043]

I don't think we need the granularity of promise-resolvers. For temporal is understandable because we're planning to gate every builtin behind a feature, but additions to existing builtins can exist in experimental since they're simpler APIs.

[jedel1043]

Just for the record, I do think we need a mechanism to enable experimental features individually. However, I think this can be accomplished in a backwards compatible way by using directives instead of Rust features. This would be pretty similar to how Rust handles nightly features:

• We have an array on some part of the engine with a list of the available experimental features and their current stage.
• Using directives, a user can select which experimental features they want to use, but only if the experimental feature is enabled.
• At execution time, we check the directives of a script/module, and if it has the corresponding feature, we inject it into the global object then remove it after execution finishes.
• Finally, for users who want to expose some features for all scripts, we can take a features argument on Context creation and that'll take care of injecting the additional features without removing them.