Over time Sumatra accrued code using different naming styles.

Let's fix that.

This document describes the naming style we should use in
future code (and, as a low priority, convert existing code
to that style).

Coding styles are always controversial because they are mostly
a matter of opinion.

This coding style follows 2 main principles:
* codify the style that is already used frequently in Sumatra
* clean looking code (which is e.g. why we avoid "_" prefixes or postfixes in names)

1. Naming classes, methods, functions, variables
------------------------------------------------

The best way to describe naming style is via examples.

struct ThisIsStruct
{
    bool    firstMember;
    int     second;
    char    seeHowWeAlignNames;
};

class ThisIsClass
{
    bool   firstDataMember;
    int    second;

    bool   ThisIsMethod(int inArgsGoFirst, WCHAR *outArgsGoLast);
};

bool ThisIsFunction(int inArgsGoFirst, int *outArgsGoLast)
{
    bool   variableName = true;
    *outArgsGoLast = 5;
    return variableName;
}

int gThisIsGlobalVariable;

2. Tabs vs. spaces
------------------

We use spaces, not tabs, with 4 space indentation.

3. #include statements
----------------------

Our include scheme is not traditional. The rules are:
- .h files don't #include other .h files
- we don't have traditional #ifdef .h header guards
- .cpp files #include "BaseUtil.h" first and then all the necessary
  .h files from
  1. src/utils
  2. rendering engines (which can be used for other applications as well,
     e.g. EngineDump, IFilter, PdfPreview)
  3. layout controllers (which could be used mostly independently of SumatraPDF as well)
  4. ui
  (.cpp files should not include any headers from a group below their own)
