Introduce a abstraction for scalar values

Before this possible scalar values where hard coded to be representable
in one of the following types: `i32`, `f64`, `String` or `bool`. This
restricts what types of custom scalar values could be defined. (For
example it was not possible to define a scalar value that represents a
`i64` without mapping it to a string (that would be not efficient))

One solution to fix that example above would simply be to change the
internal representation to allow it represent a `i64`, but this would
only fix the problem for one type (till someone want's to support
`i128` for example…). Also this would make juniper not following the
graphql standard closely.

This commit tries to explore another approach, by making the exact "internal"
representation of scalar values swappable (in such a way that a down
stream crate could provide it's own representation tailored to their
needs). This allows juniper to provide a default type that only
contains the types described in the standard whereas other crates
could define custom scalars following their needs.

To that we need to change several things in the current implementation
* Add some traits that abstract the behaviour of such a scalar value representation
* Change `Value` and `InputValue` to have a scalar variant (with a
  generic type) instead of hard coded variants for the standard
  types. This implies adding a generic parameter to both enums that
  needs to be added in the whole crate.
* Change the parser to allow deciding between different types of
  scalar values. The problem is basically that the original parser
  implementation had no way to know whether a parsed integer number is
  a `i32` or a `i64` for example. To fix this we added some knowlege
  from the existing schema to the parser.
* Fix some macros and derives to follow the new behaviour

This also contains a unrelated change about the way `juniper_codegen`
resolves items from juniper. In detail the `_internal` flag is removed
the the resolution is replaced by an macro. This is a drive by change
because I was annoyed of adding new items to that list.

juniper/Cargo.toml

@@ -38,6 +38,7 @@ fnv = "1.0.3"
 indexmap = { version = "1.0.0", features = ["serde-1"] }
 serde = { version = "1.0.8" }
 serde_derive = { version = "1.0.2" }
+erased-serde = "0.3"
 
 chrono = { version = "0.4.0", optional = true }
 serde_json = { version="1.0.2", optional = true }