Prototype implementation for self-contained objects

[Sebastian Huber]

https://lists.rtems.org/pipermail/devel/2015-July/011989.html

Its fully functional and well tested.  It is based on the FreeBSD support:

https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/rtems-bsd-muteximpl.h
https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-bsd-muteximpl.c

It is used to implement the Newlib internal locks and the libgomp (GCC OpenMP
support) operating system services.

There is one issue I am not that happy about.  There are two thread queue
definitions:

1. in Newlib <sys/lock.h>

struct _Thread_queue_Queue {
	struct _Thread_queue_Heads *_heads;
	struct _Ticket_lock_Control _Lock;
};

2. in <rtems/score/threadq.h>

typedef struct {
  Thread_queue_Heads *heads;

  /**
   * @brief Lock to protect this thread queue.
   *
   * It may be used to protect additional state of the object embedding this
   * thread queue.
   *
   * @see _Thread_queue_Acquire(), _Thread_queue_Acquire_critical() and
   * _Thread_queue_Release().
   */
#if defined(RTEMS_SMP)
  SMP_ticket_lock_Control Lock;
#endif
} Thread_queue_Queue;

In RTEMS the lock is optional.  In Newlib the storage must be always present
for the lock to be independent of the actual RTEMS build configuration.  I
ensure with static assertions that the layout of these two structures is
compatible (see top of cpukit/score/src/mutex.c).  For the Newlib definition it
would be sufficient to provide a structure with arbitrary content.  Only the
alignment and size must fit (see glibc header files for objects shared by
user/kernel space).  For debugging purposes it is quite handy to have an
identical layout.  I use a cast to get the score definition, e.g.

static Thread_queue_Queue *_Futex_Get_thread_queue(
  struct _Futex_Control *futex
)
{
  return (Thread_queue_Queue *) &futex->_Queue;
}

This may, however, lead to strict aliasing problems.  I am not sure how to
solve this technically best.