perf: migrate and use fd_base58 algo

[sonicfromnewyoke]

Problem

mr-tron/base58 is a general-purpose approach with O(n^2) in the input size
for solana workloads this is a hot path: every PublicKey.String(), Signature.String(), log line, JSON marshal, and RPC response-parse hits it
at a sustained throughput of a few hundred thousand encodes per second, the allocator and divide unit become measurable bottlenecks

Summary of Changes

migrate fd_base58 package specialized for solana's fixed-size types (32-byte pubkeys/hashes, 64-byte signatures)
also five8 (which is in use for rust SDK) was used as a reference

Benches

Operation	mr-tron	base58	Speedup
PublicKey.String()	937 ns, 2 allocs	57 ns, 1 alloc	16.4x
PublicKeyFromBase58()	269 ns, 2 allocs	46 ns, 0 allocs	5.8x
PublicKey.MarshalJSON()	~1020 ns, 3 allocs	63 ns, 1 alloc	16.2x
Signature.String()	3650 ns, 2 allocs	276 ns, 1 alloc	13.2x
SignatureFromBase58()	908 ns, 2 allocs	258 ns, 0 allocs	3.5x
base58.AppendEncode32	—	48 ns, 0 allocs	—
base58.AppendEncode64	—	267 ns, 0 allocs	—

[cloakd]

@sonicfromnewyoke we also implemented the fd base58 - not sure if it will be more performant or not but just noting down here for reference: https://github.com/Gealber/base58

[sonicfromnewyoke]

@sonicfromnewyoke we also implemented the fd base58 - not sure if it will be more performant or not but just noting down here for reference: https://github.com/Gealber/base58

op	ours	gealber	speedup
Encode32	55 ns	93 ns	1.68x
Decode32	45 ns	92 ns	2.03x
Encode64	232 ns	256 ns	1.10x
Decode64	177 ns	229 ns	1.30x

the 32-byte speedup comes mostly from hand-written ARM64/AMD64 assembly for the matrix-vector multiply

so, i'd recommend migrating to ours implementation right after this MR will be merged