(Re-)allow PD priority of 254

This partially reverts 9d6b4e09663d4192b00d1c219d28d2b299659d55 where the maximum possible priority allowed for a PD was decreased from 254 to 253.

This would break many, many existing Microkit systems and even though it is a trivial fix, I do not think it is worth it for users.

Previously, the monitor was the initial task and so it had the maximum seL4 TCB priority by default, 255.

Because the monitor is a fault handler and it has some other responsibilities such as converting PDs to passive PDs during init, it makes sense for it to be always the highest priority thread in the system. Hence, the maximum priority of any PD was 254, one less than the monitor’s priority.

Now with the capDL transition, we have another run-time component involved, the capDL initialiser. It is the initial task now and so it gets the default priority of 255. If the monitor also had a priority of 255 it would mean that some debug printing with the initialiser would get interleaved/messed up which looks unprofessional, so we made the monitor have priority 254 and then all PDs got 253 or lower.