wasm: make integer/string builtins available to the -os browser target

[enghitalo]

Description

On the -os browser wasm target, anything that needs integer→string conversion fails to compile:

fn main() {
	println(42)          // error: cannot implicitly convert as argument does not have a .str() function
	println(max_int)     // error: undefined ident: max_int
	n := 7
	println('n=${n}')    // error: cannot interpolate type without .str()
}

(and a program that gets past the checker hits the encoder panic called function int.str does not exist.)

Root cause

int.str() and the other int→string helpers, the min_int/max_int builtin constants, and tos() are defined in:

• vlib/builtin/wasm/wasi/int_notd_no_imports.v
• vlib/builtin/wasm/wasi/string_notd_no_imports.v

vlib/v/builder/compile.v only adds the wasm/wasi/ builtin dir for -os wasi; for -os browser it adds wasm/browser/, which provides println(string)/panic/eprintln but no integer formatting. So integers can't be printed on browser.

Fix

Both files are pure (no import, no wasi/JS-specific calls — tos just wraps string{str, len}, the int helpers are arithmetic over a digit_pairs const). Move them from vlib/builtin/wasm/wasi/ to the shared vlib/builtin/wasm/ dir so both browser and wasi builds compile them.

No symbol conflicts: neither the browser nor the wasi builtin_notd_no_imports.v, nor the shared string.v/builtin.v, defines tos or int.str.

This is a follow-up to #27450 (which fixed the -os browser eprintln panic).

After

$ v -b wasm -os browser -o ints.wasm ints.v   # compiles

-os wasi is unaffected (it picks the same files up from the shared dir now); the full vlib/v/gen/wasm/tests/ suite passes.

Tests

Adds vlib/v/gen/wasm/tests/browser_int_builtins_test.v (compiles a browser program using println(int), int.str(), integer concat, and min_int/max_int).

Checklist

• v test vlib/v/gen/wasm/tests/ passes
• -os wasi regression-checked
• v fmt -w applied