and deleted safeclib__private

deleted sources

my main dev platform

prepare for versioned docs

via make gh-pages

Revert some #4 changes to argument names (of cosmetic nature).

bump version to 2017-08-24
See #6

dist the 2 generated architecture-specific headers.
They are needed.

added docs man perf targets, docs and man via doxygen.
man needed a pre-gen markdown file and some post-gen cleanup.

The following tags were used:
* @brief: Tells in brief the functionality of functionality.
* @details: Tells complete description of the functionality.
* @param: Tells about the parameters used by function. [in] denotes parameter is an input & [out] denotes parameter is an output.
* @remark: Tells additional details about the function (E.g. Specified in/Extension to specific technical report)
* @return: Tells about what function returns.
* @retval: Tells about the return values.
 @code & @endcode: demonstarte sample code.

2) SYNCED parameter names of functions in mem_primitives_lib.c according
to parameter names used in function declaration in mem_primitives_lib.h.
The following function signatures we synced:
* mem_prim_set(): Parameter uint32_t len modified to uint32_t dmax.
* mem_prim_set16()/mem_prim_set32() : Parameters uint16_t *dp & uint32_t len were modified to uint16_t *dest & uint32_t dmax respectively.
* mem_prim_move(): Parameter uint32_t len modified to uint32_t length.
* mem_prim_move8() /mem_prim_move16() /mem_prim_move32() : Parameters uint32_t *dp, const uint32_t *sp & uint32_t len were modified to uint32_t *dest, const uint32_t *src & uint32_t length respectively.

The following two error codes are defined in safe_lib_errno.h:
ESLEMAX - "length exceeds max"
ESNOSPC - "not enough space for s2"

However, we saw in the code that ESLEMAX error code was being returned for
cases where both `if (dmax > RSIZE_MAX_MEM)` and `if (smax > dmax)`.  The
first is an invalid input condition always and the second is an invalid
input condition dependent on whether there is enough space in the
destination buffer for the source data.  Therefore we think that the second
error condition should use error code ESNOSPC instead of ESLEMAX.

The reason we discovered this discrepancy is that we are trying to provide a
common C11AnnexK wrapper interface in our code, allowing use of
compiler-specific implementations by Microsoft, IAR, and Renesas, while
using this library for GCC.  However, we need to normalize the error codes
returned and the other libraries use only error codes EINVAL(22) and
ERANGE(34) instead of the more targeted error codes used by safeclib.

GNU defines EINVAL as "“Invalid argument.” This is used to indicate various
kinds of problems with passing the wrong argument to a library function."
GNU defines ERANGE as "“Numerical result out of range.” Used by mathematical
functions when the result value is not representable because of overflow or
underflow."

In our usage of safeclib we overwrite each error code in safe_lib_errno.h to
map to either EINVAL or ERANGE.  However, ESLEMAX causes problems because it
is used for both situations in the code.  Therefore we are proposing that
ESNOSPC 'no space' is more appropriate for the ERANGE situtations where
there's a possible overflow condition, and suggest a definition
clarification in safe_lib_errno.h that ESLEMAX is "length exceeds
RSIZE_MAX".  I know that safelib uses string- and memory-specific RSIZE_MAX
variables so we could be more exact and list those, but I thought this
description was acceptable and succinct.

The changes in this commit were co-authored with Arjun Gour, my coworker,
who has approved of submitting his work back to this open source library.

Add 'restrict' keyword to all implemented interfaces per the C11 Annex K
standard.
"The restrict keyword is a declaration of intent given by the programmer
to the compiler. It says that for the lifetime of the pointer, only the
pointer itself or a value directly derived from it (such as pointer + 1)
will be used to access the object to which it points. This limits the
effects of pointer aliasing, aiding optimizations." per
[wikipedia](https://en.wikipedia.org/wiki/Restrict).

Note that compilers often implement a compiler-specific keyword version
of 'restrict' and may or may not actually define the standard 'restrict'
keyword itself. For instance:
GCC: __restrict__ and __restrict
MSVC: __restrict
IAR: _Restrict
Renesas RX Hew: _Restrict and restrict

We solved this in our code by using a "restrict.h" header which would
conditionally define the restrict keyword for known compilers. Another
method in cmake is to test compiling code with different versions of the
'restrict' keyword to determine which one is available and then mapping
the 'restrict' keyword to whatever is available. However, this
repository in `configure.ac` uses `AC_C_RESTRICT` keyword which gnu
[defines](https://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/C-Compiler.html)
as:

> If the C compiler recognizes the restrict keyword, don't do
  anything. If it recognizes only a variant spelling (__restrict,
  __restrict__, or _Restrict), then define restrict to that. Otherwise,
  define restrict to be empty. Thus, programs may simply use restrict as
  if every C compiler supported it; for those that do not, the makefile
  or configuration header defines it away.

So there should be no harm in inserting the `restrict` keyword for all
applicable pointers per the standard since it would either be removed or
matched to each compiler's keyword.

The changes in this commit were co-authored with Arjun Gour, my
coworker, who has approved of submitting his work back to this open
source library.

Fixup the wrong strljustify_s fixes,
add the failing testcase.