Fix doom running at 32FPS instead of desired 35 FPS.

[diekmann]

A simple typo set the TICRATE to 32 instead of 35.
The C sources clearly say it should be 35:
linuxdoom-1.10/doomdef.h:#define TICRATE 35

Wow, I was debugging for so long why I only see 35 FPS in the browser. I was blaming a bad interaction between the 60 FPS the browser renders animations frames vs. the 35 FPS doom likes, which are not a multiple of each other.
After 12 browser frames and 7 doom frames (at 200ms), both are in sync again.

Here is the python script to simulate how late a doom frame will be:

pdf = 0 # previous doom frame
for browser_frame in range(12+1):
time = browser_frame1/601000 #ms
print(f"Broser frame {browser_frame} at {time:.2f} ms")
pending_doom_frame = 1/35*1000 * pdf # ms
if pending_doom_frame <= time:
print(f" new doom frame for {pending_doom_frame:.2f}; delayed for {time-pending_doom_frame:.2f} ms")
pdf += 1

Output:
Broser frame 0 at 0.00 ms
new doom frame for 0.00; delayed for 0.00 ms
Broser frame 1 at 16.67 ms
Broser frame 2 at 33.33 ms
new doom frame for 28.57; delayed for 4.76 ms
Broser frame 3 at 50.00 ms
Broser frame 4 at 66.67 ms
new doom frame for 57.14; delayed for 9.52 ms
Broser frame 5 at 83.33 ms
Broser frame 6 at 100.00 ms
new doom frame for 85.71; delayed for 14.29 ms
Broser frame 7 at 116.67 ms
new doom frame for 114.29; delayed for 2.38 ms
Broser frame 8 at 133.33 ms
Broser frame 9 at 150.00 ms
new doom frame for 142.86; delayed for 7.14 ms
Broser frame 10 at 166.67 ms
Broser frame 11 at 183.33 ms
new doom frame for 171.43; delayed for 11.90 ms
Broser frame 12 at 200.00 ms
new doom frame for 200.00; delayed for 0.00 ms

This means, a doom frame is at most displayed 14.29 ms too late. This seems okayish to me for now.

Simply fixing the typo is good enough for me.