feat: extend Render(path) to support additional response types?

[proggR]

While I admittedly haven't dug as deep as I need to yet into how Render(path) works, I've recently pushed a candidate web framework @ #866 and as I was building it, the ability to leverage it to support proper JSON APIs was floating through my head. I pushed it in the state it's in largely to avoid the scope creep I could feel it tugging me into... but can't help but feel like floating the idea of a proper API oriented version of Render might be worth discussion (which at the project level would IMO reduce to supporting a way to specify response encoding type, beyond which devs could do our thing and extend it, but again I'm a n00b so if this is already possible, I could already do it and would happily add it to web).

One thought that comes to me as I play with this/contrast & compare it to past experiences is that... if Render weren't quite so tied to a specific version of what "rendering" means, there's a viable angle to not only serve rendered Markdown, but instead to serve back whatever format in whatever requested format is presented, including the omnipotent JSON support. Which while I could bake into the web framework and just run with, utilizing something like "blah.json" oriented paths to support, IMO would be better served if properly addressing any and all API oriented needs of projects at a lower level, including those discussed at #575 (ie: the ability to turn emit (at least)/log events into gno readable form).

Thoughts? Or links to how this is already handled and I just don't know about it so I can hack it into the web package? My ideal end-goal isn't to just transform data I can already feed to the web render function into JSON, but to avoid web3 devs ever needing to interact with a third party for event data like EVM devs do with Alchemy/Infura... if I had to render my biggest complains about web3 dev to anything at this point, its largely that... that I have to assume counterparty risks to handle event emitting data, which just feels wrong/counterproductive IMO. If Gnoland could solve for that, I'd be forever a fanboy, and can almost see an angle to hack it out myself if only the lower level support either existed... or I knew about its existence :\ lol

[moul]

Regarding #439, we seek to balance a markdown-centric approach with the ability for developers to integrate Gno as a backend for their external frontend.