Refactor DB Backends

[moul]

Regarding the current and past discussions: #1012, #1008, #130, #305, #131, #196, #197, #1009.

We've noticed some unused and potentially broken backend code in our project. Despite considering PebbleDB as a better replacement, we are still using GoLevelDB.

When we attempt to integrate Gno with other platforms like WASM or build it with new constraints, we encounter issues related to Cgo or advanced OS features used by those dependencies.

We have an excellent tm2/pkg/db library that abstracts the database concept and enables easy configuration. However, instead of providing configurable flags, we've hardcoded the backend selection in multiple places.

Here's my suggested plan:

1. Ensure that our current target environments use sensible defaults (e.g., GoLevelDB everywhere or different backends for computers and WASM) - already in progress in feat: make gnovm wasm-friendly #1012.
2. Add any missing drivers, including Pebble, and conduct thorough benchmarks and stability checks.
3. Switch the default to the best new drivers for a trial period.
4. Clean up all other unused backends.

This plan aims to improve database backend handling and enhance overall project stability and performance.

[thehowl]

I think it makes sense to understand ahead of the launch at least if it makes sense to switch over to pebble or something else, with benchmarks. I assigned @ajnavarro as our in-house DB magician, if he's willing to take it up.