[Draft] Code style

This is a very beginning of defining a code style of the lib

1. Use using instead of typedef - using is more readable
2. Class can have super alias in its' score only to its' superclass. Otherwise give it a different name
3. Curly braces after if, for and while must be put on the same line not on the next one - same code less lines
4. All classes/structs are named with lowercase with underscore just like std's ones - one of sqlite_orm's goals is to look like it is a part of stdlib: storage_t, table_type, statement_binder
5. private variables are named with camelcase: needQuotes, compositeKeyColumnNames
6. public functions are named just like classes: begin, make_table, bind
7. every #include from stdlib must have a list of functions/classes from it which are used in a current source file. These lists must be actual to keep includes in actual state and remove excess once they are not required: #include <string> // std::string, #include <cstddef> // std::nullptr_t, #include <algorithm> // std::find_if
8. don't write constructors which can be replaced with initializer list constructors - less code -> same result
9. don't make member field private/protected with single lined getter/setter - make a public field instead. Once you need logic in setter or getter - then make a refactoring, move to private/protected and add getter and setter. Least of getters and setters require logic but single field logic increases code from one line to seven:

public:
    int myField = 0;

vs

private:
    int myField = 0;
public:
    int getMyField() const {
        return this->myField;
    }

    void setMyField(int value) {
        this->myField = value;
    }

10. always use this while accessing member fields and member functions cause it makes reading complicated template code easier
11. use std::string &str instead of std::string& str cause & and * are not a part of a type:

int* a, b;

doesn't declare two pointers but one pointer and one int. Same for return type of functions

12. Place curly braces always after if, for, while and do operators even if body contains one line - someone may add line after you and forget to place curly braces and you'll get incorrect behavior which probably compiles well
13. Avoid using C macros - macros make compilation complicated especially when the project is large and has a lot of third party libs
14. Use enum class always instead of legacy enum - enum class allows making a clearer code