Added unsafe ppmpf tuple bind function, completing 'binding' (#18).

The introduction of PPMPF_UTUP_BIND allows for placeholder binding within the
range [1,9] to occur for a given macro function but in this case, no enclosure
removal / persistence semantics are valid, only ordinality. However, when
using the _0,__0 placeholders in the 'return' signature enclosure rules for
the result of the expansion of the macro apply and not, respectively.
Added tests for ppmpf safe / unsafe tuple 'bind' (#18).
Several changes, preparing for n-ary implementation of the bind macro.

This commit introduces the PPMPF_BDS* constructs that are to be used in the
final version of "binding". The two macros already available in testing mode,
PPMPF_TUP_BIND and PPMPF_UTUP_BIND are the proof of concept but do not
respect n-arity. This commit paves the way for their final implementation
and deployment of said feature within high order function semantics at the
preprocessor level, and is related to issues #18 and #20.

Also introduced:

    *) PPMPF_NNX macro in core files (next of [0-9] single digits).
    *) Ability for function macro binding to deal with "constants", provided
       these are passed enclosed in a _(...) marker during the "binding"
       signature.
    *) Some initial workup on the way documentation is to be handled in
       odreex, starting with macros, in the new bind.hh ppmpf file.
Candidates for effective ppmpf bind support: PPMPF_BDS30, PPMPF_BDS31

Several changes and additions in order for function binding notation to
be available in both separate and high order function macros as present
in ppmpf. Other changes in compilation flags during tests. This commit
affects issues #9, #18, #20 and relatively issue #6 as well given its
dependency upon supporting ppmpf function binding signatures in high
order function macros using that eventual macro "type" system.

Of special interest are the following details:

    1) Introduced the pfld constructs in odreex/ppmpf/kernel/pfld
       in order to ensure non conflicting expansions in deeply nested
       and highly interdependent macro constructs depending on recursive
       expansion. This will eventually change the purpose of the old
       <odreex/ppmpf/algorithms/fold.hh> contents to just folds and
       not holding key mechanisms for recursive expansion based 
       recursive application of macros when high order functions are
       deployed in ppmpf.
    2) The major candidate for implementing a high order map function
       over safe / unsafe tuples is the PPMPF_BDS31 macro which is to
       be used for evolving current PPMPF_TUP_MAP, PPMPF_UTUP_MAP into
       forms accepting both binding notation and plain old function
       macros.
    3) The function binding notation semantics for PPMPF_BDS31 are the
       following:
         *) Placeholders are comprised of a single or double underscore
            followed by a number in range [0,9]. Single underscore ones
            means that no removal of balanced parenthetical enclosure
            occurs. Double underscores remove said enclosure.
         *) Placeholder ranges of [_1,_9] and [__1,__9] are used as
            argument ordinals in final function application over the
            entire series of arguments involved.
         *) The constant placeholder is introduced as an underscored
            balanced parenthesis in the form of _(...) where ... can
            be substituted by any content by the end user. During
            argument substitution, the content will be passed as an
            argument without balanced parenthetical enclosure.
         *) The function meta - description in the "binding" signature
            for a given function f is expressed as a 2-tuple where the
            first item is the function macro identifier itself and the
            second item is a 2-sequence where the first item can only
            be of placeholder set {_0,__0}. The second item is actually
            a n-tuple of placeholders in range [_1,_9] and [__1,__9]
            in any combination with any number of constant placeholders.
    4) PPMPF_BDS30 is the prototype that is going to be deprecating the
       current proof of concept PPMPF_TUP_BINDER and PPMPF_UTUP_BINDER
       macros.
    5) When building tests, -fconstexpr-depth=1024 is choosen as the
       new default for constexpr default recursion depth and thus is
       from now on passed as a flag during compilation.

A test has been added especially in tests/ppmpf/bds31.cc for PPMPF_BDS31
that can be compiled and run with 'make just ppmpf/bds31.cc'. Of note,
there are still optimizations to be made to the constructs involved in
such an expansion mechanism.
Added PPMPF_ISPRN, removed odreex/ppmpf/parsing.

The implementations for parsing ppmpf tokens in odreex/ppmpf/parsing
should have been already removed since they are not to be used anymore.
For the recognition of a balanced parenthetical enclosure, PPMPF_ISPRN
is introduced in <odreex/ppmpf/kernel/cpro/empty.hh>.
PPMPF_MAP as a first ppmpf bind - aware prototype.

With the work done on PPMPF_BDS31, a ppmpf branching expression was used
in order for the PPMPF_TUP_MAP / PPMPF_UTUP_MAP to become bind - aware.
The newer macro is at its 3rd generation and is to be the prototype
upon which PPMPF_TUP_MAP, PPMPF_UTUP_MAP and PPMPF_SEQ_MAP are going to
be unified and become bind - aware. Affects series of dependent issues
#6, #9, #18, #20. The macro has its own dedicated test that can be
checked with 'make just ppmpf/map.cc'. This macro is going to be used
as the model upon which the other high order function emulators are
going to evolved into macros with "binding" and "type" features like the
left and right folds, zip, zipwith.
Various prototypes for ppmpf binding and typeclauses.

This is an experimental merge with several other edits, layout changes
and other optimizations related to both the binder and typeclause
implementations for ppmpf (see #6,#18,#20). The PPMPF_TMAP prototype
has been substituted by the PPMPF_QMAP one which supports the following:

    1) Distinguishes between safe and unsafe ppmpt tuples through the
       use of typeclause constructors PPMPF_STUP, PPMPF_UTUP that have
       only to be used once (during the declaration of the ppmpf
       collections themselves, completely unrelated to PPMPF_QMAP).
    2) Plain function macro identifiers as well as complex expressions
       with ppmpf placeholders and their "dereferencing" semantics.

Other changes include:

    1) The <odreex/ppmpf/kernel/cpro/core.hh> has been reedited and
       fully documented to an in - house documentation format that is
       to be used by odreex for producing the documentation for the
       whole project.
    2) PPMPF_TYPEFY, PPMPF_QTAT have been added to facilitate typeclause
       dispatching and faster but limited range [0 - 9] index access
       for comma separated tokens in ppmpf tuples.
    3) The concept of multilevel function metahandlers is to take hold
       on typeclause dispatching. See PPMPF_MAP_MHD and PPMPF_MHD as
       initial implementations upon which PPMPF_QMAP depends in order
       to do typeclause dispatching.
       
Although successive refactorings are to deprecate all the temporaries
used for developing the PPMPF_QMAP prototype, they remain, with their
tests for the time being. The last thing remaining for PPMPF_QMAP is
integration with ppmpf sequences and thus, resolve the conceptual
underpinnings of issues #6,#18,#20.