feat: Handle auto parsing Dates from string

[cycle4passion]

Before submitting a PR, I wanted to have some input for desirability/fit for a feature which handles JS dates.

It would use reviver function to regex test for isoDate string and if so, return Date type.

General idea,

const isoDate = /^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?Z$/;
const dateReviver = (_, value) => typeof value === 'string' && isoDate.test(value) ? new Date(value) : value;

return JSON.parse(raw, dateReviver);

Also should add the support of Temporal types would future proof this is as well.

[niketpathak]

I think a generic reviver function could be a good idea. However, it makes more sense to pass the reviver function as an optional argument within the toplevel config options of this library so it would not affect all users (like the one's not using dates or not needing any extra parsing). Temporal is still new, but this approach could futureproof things. Also, users should be warned of running the regex on every item in the json tree (which has a perf cost on scale).

[cycle4passion]

That sounds great. Three follow-ups:

1. Should it support a replacer for JSON.stringify too? Feels like the symmetric counterpart and would round out the API. I was not aware, but JSON.stringify for a typeof BigInt throws in JS. This would handle that quirk.

2. What do you think about a top-level preset config option? (Name suggestions welcome.) It would accept an array of strings naming built-in presets — e.g. "Date" and "BigInt" — and compose the appropriate replacer/reviver pair under the hood. If the user also passes a custom replacer/reviver, those would run after the presets.

storageConfig = {
  ...
  preset: ["Date", "BigInt"]
}

3. I am a Sveltekit developer. The same pages are called on both server and client commonly. Your library works for this as it fallsback to memory storage when localstorage is unavailable on the server. Are you ok with a README.md addtion explaining this.