Add utilities and documentation

Add portable filesize and logging C libraries and documentation for development.

doc/2.0_DEVELOPMENT/2.1_VERSIONING

@@ -0,0 +1,90 @@
+2.1 VERSIONING
+==============
+
+    The version-scheme used to track progress.
+
+I. Basic Structure
+------------------
+
+    u.v.w-x.y
+
+    Major Version
+
+            The first number, "u" in the example, represents the current major
+        version. A major version of "0" means that the software is not fully
+        complete; it's only incremented when backwards compatibility is lost.
+
+    Minor Version
+
+                Minor versions utilize the second number, "v" in the example,
+            and are incremented when new features are added.
+
+    Patch
+
+            Patches, "w" in the example, are generally small releases that only
+        fix bugs and make small improvements to the existing feature-set.
+
+    Pre-Releases
+
+            Preleases fill-in the "x" and "y" in the example. These indicate
+        that the release is either an alpha or a beta, meaning that it is
+        unfinished or not fully tested. To continue, the suffix (x), will be
+        replaced with an "a" for alpha releases, a "b" for betas, and an "rc"
+        for release candidates. To iterate, the "y" is substituted with a
+        number that is incremented with each passing alpha or beta release.
+        Please note that the "-x.y" extension is only added for pre-releases,
+        and is absent in stable versions.
+
+    Full Example
+
+        1.3.7-b.4
+
+                Represents the fourth beta of the seventh patch for the third
+            minor version of the first major release.
+
+II. Branches
+------------
+
+        This software utilizes branches in order to organize new features and
+     remove bugs as they move down the "pipeline" or "stream".
+
+    Pre-Alpha
+
+            All new features begin within their own Git branches. This allows
+        them to be contained and prevent breakage caused by other features. Once
+        an extremely early version of the feature is complete, it is moved into
+        the "Alpha" branch.
+
+    Alpha
+
+            During the "Alpha" stage, features will most likely be buggy and
+        more prone to problems; the goal of alphas in this project is to fix any
+        critical bugs and complete the feature. During this phase, features
+        are merged into a staging branch that will eventually become the future 
+        "stable" branch.
+
+    Formatting: x.y.z-a.x
+
+    Beta
+
+            The "Beta" stage comes once a feature is complete, but still needs
+        further testing. The "freeze" applied to further development of the
+        feature prevents excess bugs from appearing.
+
+    Formatting: x.y.z-b.x
+
+    Release Candidate
+
+            By this stage, critical issues have been resolved, leaving only
+        final testing to be done.
+
+        Patches begin here, as they do not require a full alpha or beta build.
+
+    Formatting: x.y.z-rc.x
+
+    Stable
+
+            "Stable" is the end-user release and is based on the branch of the
+        same name.
+
+--- end of 2.1 VERSIONING ---