ErasureCode: proofread abstract API documentation

* Andreas-Joachim Peters suggests to reduce copies to the minimum. When
  possible the output arguments will just point to the input
  argument. This must be documented as any side effect on the input
  argument may modify the output argument

* Fix typos

* Fix may/could/must/should to better reflect what's mandatory and
  what's not.

* Reword the explanation of minimum_to_decode_with_cost to not suggest
  an implementation. This will need to be revisited anyway, when the
  semantic of the cost is defined.

* Explain chunk size constraints

Signed-off-by: Loic Dachary <loic@dachary.org>
ErasureCode: improve API implementation example

* minimum_to_decode and minimum_to_decode_with_cost are replaced with
  meaningfull examples instead of placeholders

* encode and decode are commented and hard coded constants are replaced
  by defines for readability

* run against valgrind

Signed-off-by: Loic Dachary <loic@dachary.org>
ErasureCode: plugin loading in progress flag

The bool loading data member of ErasureCodePluginRegistry is
set to true when a plugin is being loaded, to provide an observable side
effect for test purposes.

Signed-off-by: Loic Dachary <loic@dachary.org>
ErasureCode: complete plugin loader unit tests

* TestErasureCodePluginExample.cc is renamed to TestErasureCodePlugin.cc
  because it's not limited to the example which is really used to
  support tests rather than being tested.

* Bugous plugins are added to exhibit failures and enable the unit tests
  to check they are handled as expected

  ErasureCodePluginFailToInitialize : the entry point returns != 0
  ErasureCodePluginFailToRegister : the plugin registry is not updated
  ErasureCodePluginMissingEntryPoint : the shared library has no entry
  point

* It would be difficult to prove that the mutex protecting against
  multiple loads actually does what it is expected to because of the
  lack of thread introspection functions such as : tell me if this
  thread is waiting on this mutex. A simpler approach is chosen : create
  a thread that blocks forever when loading ( that's what the delay in
  the example plugin is for ) and then check that the lock has indeed
  been acquired. Since this mutex is merely about making sure that only
  one thread at a time runs this sequence of code, it's probably enough.

Signed-off-by: Loic Dachary <loic@dachary.org>
Merge pull request #605 from dachary/wip-erasure-code-plugin-test

erasure code plugin test