Add rtems_rate_monotonic_deadline()

[Sebastian Huber]

Depending on the scheduler selection, the rtems_rate_monotonic_period() behaves differently. In case the EDF scheduler is configured, then tasks using a rate-monotonic object have a higher priority (based on deadline) than the fixed priority background tasks. This is quite bad for applications which want to use the periods with a fixed priority just to get statistics and a deadline miss detection. The default SMP scheduler provides EDF functionality, so this is an issue while porting applications to SMP systems. To give applications more control, add a new function:

/**
 * @brief Starts a deadline and period.
 *
 * This routine starts a deadline and period.  In case Earliest Deadline First
 * (EDF) scheduling is available, then the priority of the executing task is
 * adjusted according to the specified deadline.  The next activation of the
 * executing task is specified by the period parameter.
 *
 * @param id The rate monotonic object identifier.
 * @param deadline The deadline in ticks.  Must be positive.
 * @param period The period in ticks.  Must be greater than or equal to the deadline.
 *
 * @retval RTEMS_SUCCESSFUL Successful operation.
 * @retval RTEMS_INVALID_ID No period objects exists for the specified object
 *   identifier.
 * @retval RTEMS_NOT_OWNER_OF_RESOURCE The period object belongs to another task.
 * @retval RTEMS_INVALID_NUMBER The deadline is zero or the period is less than the deadline.
 * @retval RTEMS_TIMEOUT The previous deadline was missed.
 */
rtems_status_code rtems_rate_monotonic_deadline(
  rtems_id       id,
  rtems_interval deadline,
  rtems_interval period
);

The new function uses two timing parameters to allow constrained deadlines and not only implicit deadlines.

The rtems_rate_monotonic_period() function should be changed to not alter the task priority depending on the implicit deadline. This avoids surprises while changing the scheduler to EDF in existing applications (especially while porting to an SMP system).