refactor: add null-safety API, rename unsafe function

[Yoorkin]

• deprecate Optional::get_exn, add Optional::unsafe_get, Optional::unwrap
• deprecate Nullable::get_exn, add Nullable::unsafe_get, Nullable::unwrap
• deprecateValue::cast, add Value::into and Value::unsafe_into
• rename Value::cast_from to Value::from

[peter-jerry-ye-code-review]

Unsafe type casting should not be the default behavior

Category
Correctness
Code Snippet
pub fn Value::cast[T](self : Value) -> T = "%identity"
Recommendation
Remove the unsafe cast function and only retain the new safer alternatives into and unsafe_into
Reasoning
The cast function performs unchecked type conversion which can lead to runtime errors. The new into function with null/undefined checks is safer and should be preferred.

Inconsistent deprecation warnings and documentation

Category
Maintainability
Code Snippet
pub fn Nullable::get_exn[T](self : Nullable[T]) -> T = "%identity"
Recommendation
Add clear migration guidance in deprecation messages, e.g.: #deprecated("get_exn is unsafe - use unwrap or unsafe_get based on your needs")
Reasoning
Some deprecated functions lack clear guidance on which alternative to use. Consistent and helpful deprecation messages make migration easier.

Unnecessary double checking in Value::into implementation

Category
Performance
Code Snippet
pub fn Value::into[T](self : Value) -> T {
if self.is_null() { abort(...) }
if self.is_undefined() { abort(...) }
self.unsafe_into()
}
Recommendation
Consider combining the null and undefined checks: if self.is_null() || self.is_undefined() { abort(...) }
Reasoning
The current implementation requires two separate JS interop calls. A single combined check would be more efficient.

[rami3l]

It seems that you wish to enforce the invariant that a Value cannot be null or undefined. If that is the case, you may wish to add caveats in docstrings for both the Value type and these two methods.