Allow configuring plugins

[olanod]

Currently a plugin is only a function that handles a request. Plugins should be allowed to hold some state that is initialized at registration time.

[olanod]

Thinking out loud ... we could introduce a new method to the RequestHandler(is it still a good name?) trait that constructs and returns the handler(init, new, etc.)(does this break the trait object constraint?), it could have a default implementation, maybe also add the Default trait bound? Open to better suggestions!

[olanod]

Now thinking, allowing users to use environment variables directly as a way to configure their plugins should be just fine, still some things to consider

• [ ] How Rust WASM plugin in the browser can still use std::env
• [ ] How JS plugins see variables. In the server using Deno there's a Deno.env module that could be mocked in the browser or we can create our own namespace e.g. globalThis.valorEnv.
• [ ] Registering a plugin should accept an optional env map
• [ ] Can we create an isolated environment for each plugin so two distinct plugins can have a variable with the same name?
• [ ] In the native environment we should prefixed environment variables that are handed over the plugin with the prefix out. i.e. for a plugin named foo if there is an env var named FOO_BAR the plugin should be able to read a variable BAR.