Add utilities and documentation

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

doc/1.1_ACKNOWLEDGMENTS

@@ -0,0 +1,4 @@
+1.1 ACKNOWLEDGMENTS
+===================
+
+--- end of 1.1 ACKNOWLEDGMENTS ---

doc/1.2_PRIVACY

@@ -0,0 +1,4 @@
+1.2 PRIVACY
+===========
+
+--- end of 1.2 PRIVACY ---

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 ---

doc/2.0_DEVELOPMENT/2.3_EXTENSIONS

@@ -0,0 +1,11 @@
+2.3 EXTENSIONS
+==============
+
+    For extensions minimal and embeddable scripting language is ideal. For
+this reason Lua is the preferred langauge with regard to extending the
+application, as it is extremely small, allowing for minimal overhead and
+employment in minimized builds; written in ANSI-C89, so it will run on virtually
+any platform dating back aged legacy systems; and has a profoundly
+apprehensive C API, which allows for trivial integration with minimal friction.
+
+--- end of 2.3 EXTENSIONS ---

doc/2.0_DEVELOPMENT/2.5_LANGUAGE

@@ -0,0 +1,56 @@
+2.5 LANGUAGE
+============
+
+    DISCLAIMER: this file must be updated and adapted to this project.
+
+I. Organized Codebase
+---------------------
+
+    The program is primarily written in C, and is dispersed into a variety of
+optional modules; therefore, the inclusion of other languages, dialects, and
+platform-dependent components are permitted.
+
+    This project's core and a number of its direct dependencies conform to ISO
+9899:1990, which is generally referred to as Standard C90, and is functionally
+identical to ANSI X3.159-1989 "Programming Language C", which is Standard
+C89/ANSI-C. This ensures compatibilty between the basic functionality of the
+application and legacy/"retro" platforms, which support is planned for.
+
+    In the project's core, dialect-dependent features should be omitted, unless
+they are included within a preprocessor-directive that optionalizes their
+implmentation and separates their influence from the vital structure of the
+program.
+
+    Other languages and C-dialects can be used, but they must conform to the
+modular nature and goals of the program. By default, all extraneous and
+non-vital components should be disabled; compiler-flags and build-options will
+be the primary means of enabling them.
+
+II. Styling
+-----------
+
+        The source-code in this project is formatted to the "Allman" style of
+    indentation; see the provided example below:
+
+    while (x == y)
+    {
+        function();
+        function_2();
+    }
+
+        Note that braces align with the control statement, and statements placed
+    within the braces are indented.
+
+        Allman-style indentation maximizes the readability of the program and,
+    via a clear, block-like structure, reduces the probabilty of ambiguous
+    formatting.
+
+        Each source file must have a comment at the bottom marking the end of
+    its content e.g.
+
+            /* --- end of FILE_C --- */
+
+        The period located before the extension is shown as an underscore, and
+    the name is now capitalized, whereas the real filename is snake_case.
+
+--- end of 2.5 LANGUAGE ---

doc/2.0_DEVELOPMENT/2.7_LIBRARIES

@@ -0,0 +1,32 @@
+LIBRARIES
+=========
+
+        Each library used should be widely portbale and should lack
+    platform-dependent features. Components that are not written in standard
+    C/C++ or D should be disabled by default at compilation; only being
+    enabled by flags.
+
+        Note: libraries licensed under any version of the GNU GPL should be
+    avoided, due to the fact that these licenses require that the software
+    linking them is provided under the same terms. The LGPL is an exception, but
+    instructions for replacing the library with a different version must be
+    provided, as the LGPL requires that users can easily modify the LGPL code in
+    contrast to the common misconception that this license forbids static
+    linking. In general, copyleft and strongly reciprical licenses must be
+    avoided.
+
+    1.) Libraries should always be included as Git submodules.
+    2.) Libraries should only be included if writing the same functionality
+    would take an unreasonably long period of time.
+    3.) Libraries should be platform-agnostic, or they should at least provide
+    the ability to replace components with those required on a different system.
+    4.) All libraries must be disabled by default at compilation and must only
+    be enabled via compilation options.
+
+        Adding on, all contributions must be original and not be derived from
+    the work of another person, company, software, or any other entity that may
+    generate the content in question within this document.
+
+        Header files should only be used to declare functions.
+
+--- end of 2.7 LIBRARIES ---