Many improvements

Many of the improvements here are based on C++11 features, but they can be translated easily to C++98/03. 

However, having a modern C++ compiler is easy: 
 - On windows, check [the STL's fork of MinGW](http://nuwen.net/mingw.html), GCC4.9 C++14 ready. Just download and extract.
 - On linux, just update GCC or install LLVM/CLang.

---

# Several changes:

## Standard Library compatibility
The Java-like iterators of edalib containers could be fine for teachers and students used to the Java syntax and style, but C++ is a completely different language where that practices could break its expressiveness or even kill runtime performance.

The file `iterator_adapters.hpp` contains several mixings designed to *translate* a Java-like iterator into a C++ (Standard Library compatible) iterator.   
Those are designed with transparency in mind, in a non-intrusive way. Teachers and students doesn't need to know the adapters are there, they just see a Java-like iterator. But the compiler sees a C++ iterator too.  
Also a `container_traits` trait is defined in `Utils.h` to make edalib containers follow standard library conventions.

### Why?

Java vs C++ style apart, the fact that containers and iterators follow the language conventions means that **edalib containers can be used with Standard Library features, such as algorithms, other containers, etc.**

For example, this code is perfectly valid:

``` cpp
Vector<int> edavector;

//Copies user entry into the vector:
std::copy( std::istream_iterator<int>(std::cin) , 
           std::istream_iterator<int>() , 
           std::back_inserter( edavector ) );
```

### How it works?

Just (public) inherit from the mixing `util::edatocpp_iterator_adapter`, passing the Java-like iterator type and the value type:

``` cpp
struct Iterator : public utils::edatocpp_iterator_adapter<Iterator,Type>
{
    ...
};
```

Also the container needs some traits to be fully compatible with C++. Don't worry, there are two more steps only:

 - The container should (public) inherit from the `util::container_traits` type trait, passing the container type and the value type:
       
   ``` cpp
   template<typename Type>
   class Vector : public util::container_traits<Vector<Type>,Type> {
       ....
   };
   ```

 - The container also needs proper iterator traits, Just after the closing brace of the iterator class, put the `ADD_ITERATOR_TRAITS()` macro:

   ``` cpp
   struct Iterator {
   ...
   };
   ADD_ITERATOR_TRAITS()
   ```

Thats all. Now you have a C++-ready iterator from an ugly Java-like one. See the documentation inside `iterator_adapters.hpp` for more info.

### Some notes about iterators:

 - An iterator should be always **cheap to copy**, behaving like a C raw pointer. For the same reason, **pass iterators always by value**.
 - The reason of the properties above is that **C++ iterators should act as thin value types**, just as a C raw pointer. So **C++ iterators should be default constructible always**. Even if you define protected ctors to couple iterator creation to the container, **provide a (public) default constructor too**.
 - As iterators are (should be) cheap value types, **passing them by reference has no sense**, and in fact could break performance. In functions like `insert()`, **return the updated iterator by value instead of passing it by reference**.  
*In general, modern compiler optimizations are based on value semantics, so things like returning with an extra reference parameter instead of returning by value is the worst thing you can do. Use value semantics always, trust the compiler, and if you are not sure inspect the assembly.*

## Unit testing 
Now the library includes [Bandit](https://github.com/joakimkarlsson/bandit) as a submodule, to perform unit testing in a clear way. 

The original assert-based tests are being replaced by unit tests. At this time, the `tests/test.cpp` file contains:

 - Tests to check iterator adapters on different linear containers.
 - Tests to check C++11 features on linear containers.
 - Tests to check the correct behavior of edalib container adapters.

Also the project includes a `.travis.yml` file to perform unit testing automatically when pushing to Github, via TravisCI. The environment is configured to execute the above tests compiled with both GCC and Clang compilers.

## Other changes

 - Improved portability and readability, using standard C++ constructs instead of custom types and macros.
 - Minor documentation fixes at `README.md`: Avoid cplusplus.com, hooray! Also, added some modern equivalents (`std::unordered_map`, etc) of containers defined in edalib.

Short answer: Don't be lazy and provide the proper extra overload.

Long answer: Const allows the compiler to do some assumptions about the usage of the object, leading to better optimizations. These optimization can change the code completely (An optimization in the C++ sense is "*do whatever you like with the code if the runtime behavior seems to be the same*"). So throwing away the const, to do mutable things in something designed to be inmutable, could lead to problem with the optimized code the compiler generated assuming you were doing inmutable things.

The constness of a member function (The right const) is not really about the inmutability of the function, but **about the constness of the `*this` object in the call context**. C++ has no bitwise constness, but logical constness. Thats why there is a `mutable` keyword.