Initial commit of maki icon set.

[mramato]

This is a separate pull request just to make the other I'm about to open easier to review.

The Maki icon set is used in the GeoJSON simplestyle specification and will also provide a good default icon set for use with the new PinBuilder class. The icons weren't usable out of the box, so they had to be massaged in a process that I've detailed here:
https://github.com/AnalyticalGraphicsInc/cesium/wiki/Maki-Icon-Generation for details.

[emackey]

@mramato can you describe here the current known problems with using SVG paths and/or SVG files as billboard textures, so we have a record of how we decided to use raster images instead? (I know it's a rehash of stuff we talked about in person, but it seems like it should be on this PR before it goes in).

[mramato]

I thought I mentioned it on the wiki page, but apparently I didn't (I'll update that after posting here).

Originally, I was heading down the png path for three reasons:

1. The src svgs from maki do not take up the entire image and are not always centered. This made overlying them on top of another object difficult.
2. The svgs also contain no standard identifiers or information that would allow us to easily alter the path's fill and stroke on-the-fly. For example, a lot the images have transparent rects around their border for seemingly no reason. I ad some hacky code that iterated svg nodes and colored them, but it wasn't pretty and it was very specific to how their svgs are currently structured.
3. Finally, I'll note that the svgs are considered "source" in the maki project and MapBox, themselves actually generate and use the pngs rather than the svgs directly.

That all being said, the big showstopper came when things didn't work in IE 11. It turns out that drawing an SVG to a Canvas taints the canvas, making it impossible to read the pixels back (via toDataURL or turning it into a WebGL texture). This is actually in the spec itself (because SVGs are inherently unsafe). It turns out some browsers (Firefox and Chrome) will examine the SVGs and keep the canvas clean if the SVG is only using "safe" features. IE doesn't do this and always marks the canvas as dirty. To ultimately solve this problem. the SVG working group has a proposal to add toDataURL functionality to the SVG element; standardizing behavior across browsers.

[emackey]

Thanks!