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.
A "type" system for the preprocessor using ppmpf typeclauses.

In relation to issue #6, ppmpf typeclauses refer to a 2-tuple of items
with the first being any kind of ppmpf collection, the second a decimal
number serving as a "type" identifier and referred to as typeid. This
concept is used in order to implement "overloadable" high order function
macros used in ppmpf internals, but it is more a convenient bypass than
anything else.
Using a PPMPF_TMAP prototype with ppmpf typeclauses.

Added to ppmpf typeclause tests as well, PPMPF_TMAP is an implementation
of the high order PPMPF_TUP_MAP and PPMPF_UTUP_MAP that makes use of the
ppmpf typeclauses produced by the PPMPF_STUP and PPMPF_UTUP constructors
for said ppmpf "types", per issue #6. PPMPF_TMAP can compose safely with
itself as well and always returns the correct ppmpf typeclause.

PPMPF_TMAP can be extended into an implementation taking into account
ppmpf typeclauses of sequences as well. That is the final goal within
this particular branch.
Added missing argument in PPMPF_TFY ppmpf macro.
Prototypical macro function metahandlers for PPMPF_TFY in PPMPF_TMAP.

In order to pave the way for ppmpf expressions like "bind" to be used in
PPMPF_TFY controlled expressions, the function metahandlers to which
PPMPF_TFY delegates control of expansion should be the ones controlling
the expansion of a given function macro. As an example, PPMPF_TMAP_H1
and PPMPF_TMAP_H2 test handlers are rewired to detect a parenthesis in
place of a function as an "expression" and expanding to PPMPF_UNIT()
whenever that happens. In essence:

   1) Initially, the typeid is retrieved from the ppmpf typeclause
      containing the typeid and ppmpf collection data section through
      PPMPF_TFY.
   2) PPMPF_TFY dispatches to the right metahandler according to typeid
      retrieved from the ppmpf typeclause.
   3) Metahandlers (like PPMPF_TMAP_H0 and PPMPF_TMAP_H1) take over from
      PPMPF_TFY and dispatch to either the current implementations for
      their respective typeids or to PPMPF_UNIT in case an "expression"
      (right now just a fake one represented by the () token).

Practically, this means that the final effect of PPMPF_TFY is function
"transformation" and "type" manipulation fot whatever weight these
terms may carry at the preprocessor level. An interesting, functional
construct for essentially solving issues #6 and #20!
Further adapting the PPMPF_TMAP example for PPMPF_TFY integration.

Added an empty seed argument to its handlers for making it compliant to
the signature requested by PPMPF_TFY.
Making PPMPF_TMAP example deploy PPMPF_TFY and its metahandlers.

The implementation of PPMPF_TMAP is now dependent on its ppmpf typeid
"type" metahandlers for its functionality. It dispatches correctly to
either safe / unsafe tuples. Conceptually dealing with issue #18. The
last step will be to add expression support to the metahandlers, thus
resolving issue #20 definitively as well.
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.
PPMPF_MAP is feature complete.

This commit deprecates all other map prototypes (though these may lie
around during refactoring period) and it bundles expressions, a "type"
system for the preprocessor based on ppmpf typeclauses in single macro
identifier. Both ppmpf sequences and tuples (safe and unsafe) now have
typeclauses that can be used to dispatch to the appropriate versions
of the macros involved in order to yield the effect of map as a high
order function. Closes #6, closes #18, closes #20. The same internals
are going to be used for all other high order functions already inside
ppmpf.
Several changes to ppmpf (type system, partial application, recursion).

This merge is bringing partial application and closure - like
semantics to ppmpf components, folding pipelines, ppmpf typeclauses
and similar things already described in previous commits.