efl/evas backend and backend selection

[jazh Nov 4 2010]
Similar situation as Qt. (https://blueprints.launchpad.net/linaro-graphics-wg/+spec/multimedia-linaro-qt-1105)

[jazh Oct 24 2010]
Possible solution for runtime backend selection of evas:
check environment variable (i.e, EVAS_BACKEND) -> load opengl or opengl es2.0 library depending on the environment variable setting -> resolve symbols for opengl/es APIs -> use these function pointers for opengl/es rendering
Questions:
Which library shall evas depend on, opengl or/and opengl es2.0? neither for runtime selection.
Different header files should be used for opengl and opengl es2.0, shall evas depends on them? the answer seems should also be no, then we need a new header file for unifying opengl/es definitions.
Do we need to support fixed pipeline backends (opengl 1.x and opengl es1.1)? We may need to exclude them, because backends for fixed pipeline and full programmable pipeline are really not interchangeable, and actually opengl es1.1 is not supported by evas.
Shall we use same glsl shader sources for opengl and opengl es2.0? Not needed, we can select at runtime.

[jazh Oct 22 2010]
Evas supports both opengl and opengl es 2.0 backends, function pointers (i.e, for FBO support) are used to abstract the API differences for different opengl/opengl es versions.
--enable-gl-x11 enable opengl (opengl es2.0) rendering engine
--enable-gl-flavor-gles enable opengl es2.0 flavor for opengl engine
--enable-gles-variety-sgx support 'sgx-style' runtime shader compiler
--enable-gles-variety-s3c6410 support 's3c6410-style' offline shader compiler

In Evas, neon optimization has been implemented for rotations and software rendering, it is enabled by default, and a small piece of neon program is compiled for check neon support when build evas, if compile fails, neon support will be disabled.

Upstream evas branch: http://svn.enlightenment.org/svn/e/trunk/evas/