Update Contribution guidelines

[shakedregev]

Document implicit guidelines for contributing:

• - Use squash merge when merging a feature to a main development branch and edit the commit message to describe relevant details.
• - Do not include words like "function" or "class" in function or class names. It is clear what they are based on the naming conventions.
• - ReSolve should always be capitalized in this manner, regardless of naming conventions. There may be additional words where capitalization is important and it is preserved similarly.
• - When writing a function header over multiple lines, indenting of subsequent variables should mimic the first variable.
• - Add Doxygen comments for class member functions in source files. Add Doxygen comments for classes in their header files.
• - Doxygen: explain which parameters are in, out or in,out using @param[in], @param[out] , @param[in,out]
• - Doxygen: Write a one line explanation using @brief, add a longer explanation below if necessary
• - Do not leave commented out code

[shakedregev]

@pelesh - addressed in #242.

[pelesh]

I would suggest following amendment to item 5 in your list: "Add Doxygen comments for class member functions in source files. Add Doxygen comments for classes in their header files."

We could also put @brief stanzas for member functions in header files and everything else in source files.

// Gmres.hpp

/**
 * @brief Generalized minimum residual (GMRES) solver.
 *
 * Long description of Gmres class ...
 * 
 * @note MatrixHandler and VectorHandler objects are inherited from
 * LinSolver base class.
 */
class Gmres
{
  Gmres();
  ~Gmres();

  /// @brief Runs iterative solver
  int solve(vector_type x);
};

The source file would then have something like this:

// Gmres.cpp

// some code

/**
 *
 * Long description explaining what `solve` function does ...
 *  
 * @pre The solver `setup` function has been successful and the pointer to system
 * matrix has been set.
 */
int Gmres::solve(vector_type x)
{
  // some code
}