Update OpenMP directives that have reductions to use the OMPReductionClause

[LonelyCat124]

Looking through the code for #1551 I think the ordering of some clauses may change when using reduction variables with the new infrastructure.

The old code for begin_string would return a single string, which contained "omp parallel do DEFAULT_CLAUSE, PRIVATE_CLAUSE, SCHEDULE_CLAUSE" + self._reduction_string().

The new structure of the code instead ensures that the relevant clauses are constructed, so you end up with: OMPParallelDoDirective with children:

1. schedule
2. OMPDefaultClause
3. OMPPrivateClause
4. OMPScheduleClause
5. [OMPReductionClause]

Currently I don't believe there is any implementation of how to construct the OMPReductionClause, so it is never added as a child at the moment.

In theory, all begin_string then returns is "omp parallel do", and the backend codegen handles the code generation of the clauses itself. However, since OMPReductionClause is not generated, the current code instead returns "omp parallel do" + self._reduction_string().

This means that the output would now be "omp parallel do" + self._reduction_string() + ", DEFAULT_CLAUSE, PRIVATE_CLAUSE, SCHEDULE_CLAUSE" instead.

The issue here is primarily that we should address that (though the generated code is still valid) at some point to use the clauses directily.

The side issue is that seemingly no test ever caught this, I only caught it myself when checking coverage of a different section of being_string. @sergisiso