Further rationalise our usage of assert()

Further rationalise our usage of assert()

This patch futher improves our usage of assert() and friends. The
intention is to bring clarity to which forms of assert are used in
which situations, and to solve the problem of assert(X), or
osi_Assert(X) being used in a situation where X has side-effects.

It introduces two new assertion macros opr_Assert() and opr_Verify(),
and clarifies the usage of osi_Assert() and assert().

*) opr_Assert is a direct equivalent of assert(), with the exception
   that its output can be redirected to a log file when used in server
   code. It is the preferred version of assert for libraries, and server
   side code. Note that whilst opr_Assert doesn't currently become a
   no-op when NDEBUG is defined, the intention is that it will do so at
   some point in the future.
*) opr_Verify(X) asserts if the value of X is false. Unlike assert()
   it will always run X, regardless of whether the value is checked or
   not. The eventual intention is that when NDEBUG is defined,
   opr_Verify(X) => X
*) osi_Assert is an assertion macro intended for use in kernel code,
   or in mixed kernel/userland code. When code is built for userspace,
   osi_Assert(X) => opr_Assert(X)
*) assert is the system's own assert macro. It should only be used
   in client code. Whilst a header (opr_assert.h) is provided to map
   assert() to opr_Assert(), its use is discouraged

Change-Id: Ie6d61305686bdc7193cc8690e6f4fbe363211faf
Reviewed-on: http://gerrit.openafs.org/5395
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>