Add class_evaluate for user-defined constant resolution

[obsidiannnn]

Currently, evaluation happens in the Evaluator’s binding, which prevents proper resolution of user-defined constants (e.g., CustomClass). This PR addresses that limitation.

Changes

• Added class_evaluate method to evaluate expressions in the class context
• Threaded class_binding through:
  • evaluate
  • evaluate_param_proxy_expressions
  • class_evaluate
• When class_binding is present:
  • Uses class_evaluate for correct constant resolution
• When class_binding is nil:
  • Falls back to instance_evaluate
  • Preserves existing refinements-based behavior for LowType built-in types

Impact

• Enables correct resolution of user-defined constants
• Maintains backward compatibility with existing evaluation logic

closes #40

[maedi]

I'd like to keep this comment; developers are security conscious people and need to know I almost know what I'm doing. It can be put above the class definition line if it should now be a global message due to the multiple evals in the code now. Or go above each eval

[maedi]

Can you please add a spec that tests one simple use-case that this PR fixes? A custom class?