Refactor CCEffect into CCEffect and CCEffectImpl

These changes decouple the public interface of an effect from its internal implementation and allow for one effect to have multiple implementations. This will be useful when implementing certain optimizations (different implementations might be selected based on effect property values) and for supporting different rendering APIs (OpenGL versus Metal).

Internal implementation details such as render passes, varyings, uniforms, and functions all move into CCEffectImpl and its subclasses. Public interface details such as initializers, convenience constructors, and effect properties all stay in the subclasses of CCEffect. 

At the present time, all CCEffect subclasses only have a single corresponding CCEffectImpl subclass but this may change in the future. Some CCEffect subclasses (CCEffectLighting for instance) will dynamically create new CCEffectImpl subclass objects based on changes to their property values. Most effects do not do this though and instead keep the same implementation object for the lifetime of the interface object.