Add formatting via clang-format

[cakarsubasi]

As we have already discussed, it is possible to automatically format most of GEL with a single command after a .clang-format file is setup. However, I had some trouble actually writing the format file due to the somewhat inconsistent style across the library. For example, in HMesh/smooth.cpp:

namespace HMesh
{
template<typename  T>
void for_each_vertex_parallel(int no_threads, const VertexIDBatches& batches, const T& f) {
    vector<thread> t_vec(no_threads);
    for(auto t : Util::Range(0, no_threads))
        t_vec[t] = thread(f, ref(batches[t]));
    for(auto t : Util::Range(0, no_threads))
        t_vec[t].join();
}

// ...

void laplacian_smooth(Manifold& m, float weight, int max_iter)
{
    auto vertex_ids = batch_vertices(m);
    auto new_pos = m.positions_attribute_vector();
    auto f = [&](const vector<VertexID>& vids) {
        for(VertexID v: vids)
            new_pos[v] = m.pos(v)+weight*laplacian(m, v);
    };
    for(int i=0; i < max_iter; ++i) {
        for_each_vertex_parallel(CORES, vertex_ids, f);
        swap(m.positions_attribute_vector(), new_pos);
    }
}
// ...
}

Notice the inconsistency in braces between the two functions. In addition there is no indentation after the top level namespace. In another file such as Geometry/graph_util.h:

namespace Geometry {
    using AttribVecDouble = Util::AttribVec<AMGraph::NodeID, double>;
    using NodeSetUnordered = std::unordered_set<AMGraph::NodeID>;
    using NodeSet = AMGraph::NodeSet;
    using NodeSetVec = std::vector<std::pair<double,NodeSet>>;
    using ExpansionMap = std::vector<std::vector<AMGraph::NodeID>>;
    using CapacityVecVec = std::vector<std::vector<size_t>>;

    /// Linear time counting of the number of shared members of set1 and set2.
    int test_intersection (const AMGraph3D::NodeSet& set1, const AMGraph3D::NodeSet& set2);

// ...
}

Note the lack of a line break after the namespace identifier and the indentation.

I will set this issue aside for now since it is very low importance, but it might be a good idea to decide on a specific file to base the formatting off of that has relatively few formatting inconsistencies and is illustrative for formatting purposes.

[janba]

Right. It is a good idea to enforce consistency. Frankly, my own practice has changed a bit, but there is some consistency just not with regard to whitespace and most (but not all) the principles in GEL/doc/CodingConventions.txt are adhered to. Let's keep the issue open and return to it.