Specify project() statement

Since Slicer commit r22038 [1], project statement is allowed and required.
The Slicer Extension FAQ has also been updated to mention it. See [2]

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22038

[2] http://wiki.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ/Extensions#Is_project.28.29_statement_allowed_in_extension_CMakeLists.txt_.3F
Simplify code removing unneeded call to "if(NOT Slicer_SOURCE_DIR)"

Following Slicer commit r22063 [1], such call are not required anymore.

An entry in the Slicer extension FAQ has also been added to document it. [2]

[1] http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22063

[2] http://wiki.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ/Extensions#Is_call_to_.22if.28NOT_Slicer_SOURCE_DIR.29.22_required_to_protect_.22find_package.28Slicer.29.22_in_extension_CMakeLists.txt_.3F
Simplify inclusion of VTK package

Since (1) VTK_DIR will be set by either the user or by SlicerConfig.cmake
(after calling"find_package(Slicer)") and (2) calling find_package for the
same package multiple time should not be an issue, this commit removes the
code doing conditional inclusion of VTK package.

Additionally, in case the package can NOT be found, considering the
"REQUIRED" argument is provided,  the find_package will complain. For that
reason, the code associated with "if(NOT VTK_DIR)" will never be executed
and is removed by this commit.
Improve readability by fixing indent in CMakeLists.txt
Include CMake/CTest functionality by including CTest module

For more details, see http://www.cmake.org/cmake/help/git-master/module/CTest.html
For sake of readability, keep setting of extension metadata together.

This commit is stylistic and does NOT change how the project is configured.
Remove commented code related to obsolete macro "ctkMacroCompilePythonScript"
Use non-deprecated macro "slicerMacroBuildLoadableModule"

Within Slicer 4.4 [1], the deprecated macro "slicerMacroBuildQtModule" will
be removed. This commit anticipates the removal by using the recommended
macro.

[1] http://wiki.slicer.org/slicerWiki/index.php/Roadmap#4.4_2
Fix extension packaging.

This commits move the CMake code setting up the packaging at the end
of the main CMakeLists.txt. This will ensure that all files will be
packaged.

It also removed the code setting the unused variable "CPACK_INSTALL_CMAKE_PROJECTS"
Update minimum CMake required version to match Slicer expected version.
Simplify code setting default build type if none was specified

This commit simplify the code and also ensure that no CMAKE_BUILD_TYPE
is forced in case of multi-configuration system (XCode, VisualStudio, ...).
Remove unneeded variable KSLICE_LIB_PATH and associated link_directories call

Since the libraries KSegmentor, sfm_local_canvese and KSlice are all
CMake targets, there are no need to manually call link_directories
and deal with the intermediate build directories specific to
multi-config systems (XCode, VisualStudio)
Better consistency across CMakeLists by fixing indentation

Also make use of return() statement in carreraslice_wrap/Widgets
CMakeLists.txt. Doing, the indentation of the CMake code building
the library is similar to what the final implementation would be
(without the conditional building).
Fix windows build error by including string header.

//------
Windows build error was:

  1>..\..\..\CarreraSlice\src\sfm_local_chanvese\src\interactive_kurvolver.cpp(140) : error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'std::string' (or there is no acceptable conversion)
  1>        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\ostream(653): could be 'std::basic_ostream<_Elem,_Traits> &std::operator <<<char,std::char_traits<char>>(std::basic_ostream<_Elem,_Traits> &,const char *)' [found using argument-dependent lookup]
  1>        with
  1>        [
  1>            _Elem=char,
  1>            _Traits=std::char_traits<char>
  1>        ]
  [...]
//------

Also consistently use std::cout / std::endl, calling "using namespace std;"
is considered bad practice. See [1] for more details.

[1] http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice?answertab=votes#tab-top
Merge pull request #5 from jcfr/reorganize-cmakelists-and-fix-windows-build

Reorganize cmakelists and fix windows build