split lib

[alex-s168]

in the future, the compiler structure might look like this:

non-code-executing targets + backends:

• blob?
• doc renderer
• ...

backends:

• C
• VXCC
• ...

code-executing targets:

• libc
• WASI
• embedded or scripting environments

less-C-like targets:

• JVM
• ...

All the targets that execute code, should share most of the std library, like serialization, and other utilities.

proposed structure:

	enabled for	contains
std/	code-executing targets	to-json(SerialVal), HashTable, Tuple, Maybe, to-string(U64)
backend/c	c backend	==(U64,U64), +(I8,I8), [](?[],U64), ..., intrinsics
backend/vxcc	vxcc backend	==(U64,U64), +(I8,I8), [](?[],U64), ..., intrinsics
target/libc	libc target	MemSpan, fopen, fclose, ..., expose all libc features, ...
target/wasip1	WASI P1 target	MemSpan, fopen, fclose, ..., expose all wasi features, ...
target/jvm	JVM target	MemSpan, fopen, fclose, ...

these should also be moved into separate packages

[andrew-johnson-4]

current organization for comparison

actual hard coded backends
PLUGINS/BACKEND/*/*.lsts

platform libs
PLATFORM/LIB/[target]/default.lsts
PLATFORM/LIB/[target]/minimal.lsts