Re-export dependencies

[MaksymZavershynskyi]

Currently contract developers have to export the following libraries along with near-sdk themselves:

[dependencies]
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0.45"
borsh = "0.6.0"
wee_alloc = { version = "0.4.5", default-features = false, features = [] }

The problem with that is that it makes DevX slightly worse and can create version mismatch, e.g. near_sdk::collections can use different version of borsh which will produce an obscure compilation error. We should export them into near_sdk and then contracts can access them from near_sdk::exports::. This is a common practice in Rust crates, e.g. see syn.

[evgenykuzyakov]

@nearmax @frol Feel like I got stuck with Rust: https://github.com/near/near-sdk-rs/tree/publish-0.9.3

[evgenykuzyakov]

When building cross-contract-high-level example I get the following error:

examples/cross-contract-high-level  cargo +nightly rustc -- -Z macro-backtrace        Fri May  8 11:43:34 2020
   Compiling near-sdk v0.10.0 (/Users/ekwork/code/near-bindgen/near-sdk)
   Compiling cross-contract-high-level v0.1.0 (/Users/ekwork/code/near-bindgen/examples/cross-contract-high-level)
error[E0463]: can't find crate for `serde`
  --> src/lib.rs:23:1
   |
23 |   #[ext_contract(ext)]
   |   ^^^^^^^^^^^^^^^^^^^^
   |   |
   |   can't find crate
   |   in this macro invocation
   |
  ::: /Users/ekwork/.cargo/registry/src/github.com-1ecc6299db9ec823/serde_derive-1.0.106/src/lib.rs:85:1
   |
85 | / pub fn derive_serialize(input: TokenStream) -> TokenStream {
86 | |     let input = parse_macro_input!(input as DeriveInput);
87 | |     ser::expand_derive_serialize(&input)
88 | |         .unwrap_or_else(to_compile_errors)
89 | |         .into()
90 | | }
   | |_- in this expansion of `#[derive(near_sdk::serde::Serialize)]`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `cross-contract-high-level`.

To learn more, run the command again with --verbose.

[lexfrl]

@nearmax @frol Please consider to inquire this to avoid common pitfalls related to the re-exporting practice rust-lang/api-guidelines#176

[frol]

@evgenykuzyakov Here is the fix: cb5a008

The issues are:

• serde does not really support re-exports: how to reexport Serialize, Deserialize? serde-rs/serde#1465, however, there is a workaround: Make serde-derive's implicit peer dependency on serde optional serde-rs/serde#1147 (comment):

  #[serde(crate = "...")]

  Specify a path to the serde crate instance to use when referring to Serde APIs from generated code. This is normally only applicable when invoking re-exported Serde derives from a public macro in a different crate.

  https://serde.rs/container-attrs.html

• BorshSerialize expects borsh module in the scope (when you have a borsh crate as a dependency, it imports just fine, but for re-export, we should explicitly bring it into the local scope with use near_sdk::borsh or use near_sdk::borsh::{self, ...})