refactor: rename *ify functions (DO NOT SQUASH)

[aleclarson]

Tip

The owner of this PR can publish a preview release by commenting /publish in this PR. Afterwards, anyone can try it out by running pnpm add radashi@pr<PR_NUMBER>.

Summary

• Rename listify to mapEntriesToArray
• Rename objectify to castObject
• Rename mapify to castMap
• Add src/transform folder + tests/docs/benchmarks folders
• Move toInt into the “transform” folders.
• Move toFloat into the “transform” folders.

Related issue, if any:

https://github.com/orgs/radashi-org/discussions/65

For any code change,

• Related documentation has been updated, if needed
• Related tests have been added or updated, if needed
• Related benchmarks have been added or updated, if needed

Does this PR introduce a breaking change?

Yes

A codemod should be written for this change.

Bundle impact

Status	File	Size	Difference (%)
R073	src/array/mapify.ts	0	-117 (-100%)
src/array/castMap.ts	A	0	+0
src/array/castObject.ts	D	0	+0
src/array/objectify.ts	M	0	+0
src/object/crush.ts	D	0	+0
src/object/listify.ts	A	0	+0

[aleclarson]

Decided to rename toObject (now castObject) and toMap (now castMap) as they didn't fit the naming convention below:

Naming guideline for conversion functions

• The to* convention dictates that the function should accept value: any and it should always have one argument. Effectively, the to prefix is reserved for “value parsing” functions. Our toInt and toFloat functions fit this class well.
• The cast* convention dictates that stricter parameter types and parameter count are allowed. Effectively, the cast prefix is a catch-all for any “non-destructive value transformation” task.
  • Casting functions are assumed to return a new object reference when an object return value is expected. For example, if castArray receives an array, it shallow copies it and returns the copy. This rule ensures the casted result is free to be mutated without “action at a distance”.

[aleclarson]

Also renamed toArray (now mapEntriesToArray). I believe this make it more discoverable, and it pairs well with mapEntries from a naming perspective.

Ultimately, the goal is to avoid casted and transform function groups.