Introduce entrance crate

[ascjones]

Closes #825.

:warning: Breaking Change :warning:

Problems

So why didn't we implement this already? The problem starts with procedural macros which are pervasive to the idea of ink!. There currently exists no sane way to properly deal with build system related information from within a proc. macro. For our use case it will be important to support both: using ink! crates as it happens nowadays as well as the proposed new solution via the centralized and unifying ink or ink_api crate layer.

The problem is that within a proc. macro it is hard (or impossible) to properly extract the information how exactly a project has been or will be built and therefore the proc. macro is kind of unable to properly align its generated code with respect to this. So depending on if the user actually uses this new ink_api crate or not the proc. macro is required to generate code a little differently and this is not possible without introducing impure hacks to take measures into the proc. macro itself.

To overcome this in an opinionated way, we will assume that a contract is uses the ink entrance crate, instead of individual crates. This means that the ink_lang macros will no longer work with the individual crates.