Add and remove layers dynamically

[jfirebaugh]

This PR implements the first bit of the core runtime styling API: the ability to dynamically add and remove layers.

As appropriate for a C++ API, the layers API is strongly typed: there are subclasses for each layer type, with correctly-typed accessors for each style property. This results in a large API surface area. Fortunately, this is automated, by generating the API – and the regular portion of the implementation – from the style specification.

The layers API makes a distinction between public API and internal implementation using the Impl idiom seen elsewhere in the codebase. Here, it takes the form of two parallel class hierarchies:

• Layer and its subclasses form the public API.
• Layer::Impl and its subclasses form the internal API.

As well as forming the boundary between public and internal, these two class hierarchies form the boundary between generated code and handwritten code. Except for CustomLayer and CustomLayer::Impl:

• Layer subclasses are entirely generated. (Layer itself is handwritten.)
• Layer::Impl and its subclasses are entirely handwritten.

---

There is still work to be done before this is ready to be exposed via SDK bindings:

• The types relating to property values need to be cleaned up. Conceptually, a property value is a variant with three possibilities: not set (equivalent to a default value), constant value, or function value. The property API needs to reflect this. Currently every value is treated as a function value.
• The namespacing needs to be rationalized. Everything style-related should live in the mbgl::style namespace and mbgl/style directory. (Beneath that directory there can be a layer directory for organization.)
• Accessors for the layer filter and zoom range need to be added.
• There needs to be a layer getter. I'm leaning towards map.getStyle().getLayer() as the API. Map::{add,remove}Layer would also move to Style.

[kkaefer]

Any way we can move this to Impl?

[kkaefer]

Looks good! As for the generated files, it's probably useful to have them pre-generated to be able to look at them. We could still add the generation script to the build system, and check whether files were modified and fail if that is the case.

[1ec5]

We could still add the generation script to the build system, and check whether files were modified and fail if that is the case.

How about running the generation script as part of the build, but having the script output to the checkout, as it does now?

[jfirebaugh]

For now I'm going to go with running the generator manually when you make a change. I looked at including it as part of the build step but outputting to the src directory (which I want to do) didn't fit in cleanly with our use of gyp.

[jfirebaugh]

The last commit here involves a lot of renaming and re-namespacing. Would be great to get a second opinion on my approach:

• Everything "style-related" (roughly: implementing a concept from the style specification) lives in the style subdirectory and mbgl::style namespace.
• Inside the mbgl::style namespace, don't prefix class names with Style (except for the Style itself).
• Outside the mbgl::style, use forward declarations in headers where available.
• Use using namespace style in cpp files (not in headers).