Add contributing architecture doc

[jeffcharles]

Wanted to get some feedback on what I have so far for a contributing architecture document. We can also merge and create additional PRs to revise so we have something if what's in here is good on its own but we want to add more.

[saulecabrera]

The direction looks good to me.

Are you planning on adding examples to some of the sections? For example:

javy-apis

Common JS APIs for use with a javy::Runtime. For example, console, TextEncoder, TextDecoder. If there is a standard JS API that seems like it would be useful to multiple users of Javy, it should be implemented in this crate. If this is an API specific to your use case, you should define it in a crate of your own and register the implementation using a similar approach to how the APIs in this crate define their implementations.

Adding an API implementation

1. Add a feature to the crate's Cargo.toml for your module.
2. Create a directory under src with a mod.rs file.
3. If your API implementation requires configuration, create a configuration struct for the configuration properties required in your module.
4. In mod.rs, implement the crate::JSApiSet trait. If your API requires configuration, add the configuration struct defined earlier to the crate::ApiConfig struct under a #[cfg(feature = "your feature name")] attribute.
5. If necessary, add any JS source files inside the module you're adding.
6. Add the mod to the crate's lib.rs under a #[cfg(feature = "your feature name")] attribute.
7. Add a call to your struct's register method under a #[cfg(feature = "your feature name")] in lib.rs's add_to_runtime function.

I think that those two sections could be clearer if they had some examples.