Use newly-added time conversion functions instead of direct PR_FASTHZ / PR_SLOWHZ access
Exact amount of ticks for PR_FASTHZ / PR_SLOWHZ is an implementation detail of the domain/protosw subsystem. Exposing these values directly leads to complications / broken assumptions in the code.
When exposed, these time units propagate farther to the code and it's hard to understand whether it's seconds, ticks, slow ticks, fast ticks and so on.
Some of the user-visible constants are even defined in these slow/fast ticks, making it harder to reason about.
Some of the assumptions (like (PR_FASTHZ / 2) /* 500ms */) are tied to the specific value of the constant and will fail if/when it's changed.
Address this by adding milli_to_<slow|fast>timo() functions, allowing to express the desired delay in milliseconds.