ink! trait design

# ink! trait design ### First According to [ink! issue #631](https://github.com/paritytech/ink/issues/631), `ink::trait_definition` can make a trait which can as Message Parameter and Storage Entity, but we cannot use it as a'trait' in Rust, because we cannot use it for `&dyn MyContractTraitA + MyContractTraitB + ...`, So we don’t seem to need a 'trait' from `ink::trait_definition`, `ink::trait_definition` make a trait and a `__ink_CallForwarder<T>` The T in `__ink_CallForwarder<T>` can from a `AccountID`, this can actually be used as a `stub` to complete cross calling. For contract developers, in fact, we can also implement a macro by ourselves to generate this `stub`, and further abstract through trait. Similar to the `Solidity` interface, we may consider implementing a third-party library to implement a process macro similar to `#[interface]` to generate a `#[contract]` `stub`, similar to https://github.com/patractlabs/metis/blob/master/stubs/token/erc20/lib.rs#L26. When another contract needs to use a solidity-like interface, it is to introduce this stub as an as-dependencies as a dependency, instead of using the result of trait-defination or introducing the original contract. I found the [ink! pull #665](https://github.com/paritytech/ink/pull/665) has - Generate the actual trait to forward call so that the concrete implementer can be used for cross calling. If it is same with this? ### Second Currently `event` can only be declared in #contract, This means that developers cannot define a common `event` structure for multiple contracts. In some projects, especially when the front-end shares contract code with off-chain services, this will cause code duplication. In addition, the `event` structure is currently based on rust enum, which will make it more troublesome for applications based on other languages to process events. For `event`, the event flag can be implemented based on additional eventid. This can maintain the consistency of the event and facilitate unified processing. Further due to the current implementation of `event`, the event description type corresponding to metadata is an array. For many language implementations, it is more versatile to express as a map, for example: from `[ "transfer" ]` to `{" 0","transfer"}`. For details, see: - [ink! issue #683](https://github.com/paritytech/ink/issues/683) - [ink! issue #759](https://github.com/paritytech/ink/issues/759) ### Third Why does ink!’s trait implementation method use "Trait name, method" to calculate selector instead of method name to calculate selector. If you are worried about the same method name under different traits, how to deal with traits with same name. ### Fourth Question about contract result: Implement error forwarding. - [ink! issue #641](https://github.com/paritytech/ink/issues/641#issuecomment-825343508)