[Bug]: Unsafe use of TimeLock::UnlockAt(u32) in TypeScript

### Bug description

The Move enum `TimeLock::UnlockAt` uses a `u32` value. The maximum number is 2^32 - 1 = 4294967295, which corresponds to: GMT: Sunday 7 February 2106 06:28:15

If we provide higher values when calling `.withDeleteLock(TimeLock.withUnlockAt(N))` in Typescript, i.e. 4294967296 or 999999999999999 we are observing strange phenomena because TS uses 53 bits to encode integer number values (u32 is bound to TS number by wasm-bindgen).

Cite from the wasm-bindgen docs regarding [Number to u8, i8, u16, i16, u32, i32, isize, and usize](https://rustwasm.github.io/wasm-bindgen/reference/types/numbers.html#number-to-u8-i8-u16-i16-u32-i32-isize-and-usize) conversions:

> If the JavaScript number is Infinity, -Infinity, or NaN, then the Rust value will be 0. Otherwise, the JavaScript number will rounded towards zero (see [Math.trunc](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/trunc) or [f64::trunc](https://doc.rust-lang.org/std/primitive.f64.html#method.trunc)). If the rounded number is too large or too small for the target integer type, it will wrap around.

* We need to prevent wrap arounds in the WASM API
* We may use the value 0 (corresponds to Infinity in TS) to express infinity.
* We should add equivalent TS constants i.e. `const TIME_LOCK_UNLOCK_AT_MAX_2106 = 4294967295` (or similar named) to express the maximum possible value for `UnlockAt`
* We should add `withMaximumLock2106()` and `withInfiniteLock()` functions to facilitate the usage in TS.
* the 2106 variants may be optional

### Expected behavior

* No strange phenomena because of TS number -> Rust u32 -> Move u32 type conversions
* TimeLocks allow to have infinite locks

### Can the issue reliably be reproduced?

Yes

### Example repository

_No response_

### Steps to reproduce

_No response_

### Language

WASM

### Language Version

-

### Version

v0.1.0

### Hardware specifications

-

### Additional info

-