Style guide

We try to follow common practices described in Effective Go and Google Style Guide for Go to maintain consistency across the codebase. Following a consistent coding style makes the code more readable and maintainable for everyone.

• Custom errors: New polkadot-related custom errors should implement the error interface. See #271 and linked PRs.
• Error handling: We use critical logging for resolving errors(panicing). We add logger to modules through dependency injection and we only resolve errors(critical log) in the api modules. See #315.
• SCALE types: Certain SCALE types like the Result type are common in Rust which the original Substrate implementation is based on, but add unneeded complexity in Go. When we need to return such type it's preferred to encode the data into the required type as late as possible - just when you need to return it in the api module, instead of building your logic around it. See #322.