Revert rtic from 0.5.5 to 0.5.3

[HarryMakes]

This is to fix a panicking upon initialization problem that can be resolved by reverting the update earlier taken on the rtic crate.

Since d5916c5 where rtic is bumped from 0.5.3 to 0.5.5, the compiled firmware will cause the Stabilizer panick upon powering up. With GDB, the backtrace looks like this:

(gdb) backtrace
#0  0x08020c90 in rust_begin_unwind (_info=<optimized out>)
#1  0x08017532 in core::panicking::panic_fmt () at library/core/src/panicking.rs:85
#2  0x0801f0d0 in core::option::expect_failed () at library/core/src/option.rs:1213
#3  0x08014674 in stabilizer::init (c=...)
    at /rustc/6af1bdda54abc9e919fc1137411dfc4311e05649/library/core/src/option.rs:370
#4  0x0801741c in stabilizer::APP::main () at src/main.rs:160

Doing next on GDB from the first PC will put the CPU to the panicking loop after the following code:

...
halted: PC: 0x08000334
537	                *SCB_CPACR | SCB_CPACR_FPU_ENABLE | SCB_CPACR_FPU_USER,
(gdb) n
Info : halted: PC: 0x08000336
halted: PC: 0x08000336
Info : halted: PC: 0x0800033a
halted: PC: 0x0800033a
535	            core::ptr::write_volatile(
(gdb) n
Info : halted: PC: 0x0800033c
halted: PC: 0x0800033c
550	            trampoline()
(gdb) n
Info : halted: PC: 0x08020c88
halted: PC: 0x08020c88
^C
Program received signal SIGINT, Interrupt.
0x08020c96 in rust_begin_unwind (_info=<optimized out>)

On a side note, a similar symptom where the Ethernet PHY does not get reset, as discussed in #141, might have also arisen from this new version of rtic. However, the reset delay still seems a bit too short to me.

[HarryMakes]

I have just opened an issue over cortex-m-rtic as well: rtic-rs/rtic#361

[HarryMakes]

Closed since a new solution is needed after migrating from 0.5.3 to 0.5.5: #144