Periodic synchronization of devbox with the master branch.
Removed a pointless TODO.
Towards consolidating ppmpf tuple semantics (#18).

A series of changes that make the implementation of high order function macros
for both safe and unsafe ppmpf tuples cohere. Fixes have been applied to some
misbehaving PPMPF_UTUP_* members, and the *_1EMPTY and *_1GET functions got
properly renamed to the appropriate UTUP / TUP counterparts. Most importantly
PPMPF_UTUP_JOIN and PPMPF_UTUP_MAP have been properly adjusted and easily
participating from now one in compositions.

It is important to remember the two simple requirements for using unsafe ppmpf
tuples:

    1) If the final item in said unsafe tuples is a valid macro identifier or
       a non alphanumeric character sequence, a comma should immediately
       follow it during definition of the unsafe tuple.
    2) While combinations of the unsafe variants for ppmpf tuples is allowed
       by design, there should be a guarantee by the user that the first rule
       is not violated.

Safe variants do not need to comply to these two requirements. The reason for
maintaining safe and unsafe variants is that they are both doable with little
effort with the new recursive expansion constructs, while the unsafe variants
are of help in a series of algorithms that have particular needs when it comes
to performance at the preprocessor level.
A 'bind' macro for safe ppmpf tuples, in relation to #18.
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).
Simplified make targets, errors.log logs everything from make.
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.
Making sure 'make check' runs 'make test'

By adding it to the .PHONY Makefile.am target, we turn 'make check' into
'make test' because in our deployment of the build system, the various
testing procedures are somewhat quite particular.
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.
Making sure 'make just' multiple targets build together.

Previously, 'make just' followed by a list of test targets to build
and run were built and run on a per item basis. With this commit, they
are all built together before they run all run together afterwards.
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.