Inconsistent use of synchronous and asynchronous resets

Nobody has claimed this yet.

There are resets in this design which are used as both synchronous and asynchronous
There are also resets which can assert asynchronously but are used synchronously

# Some examples
At the time of writing (1a14e8d9)

`rgmii_phy_if.sv`
- Line 252 uses `rst` as an async reset (to synchronise `rx_rst_reg` to `mac_gmii_rx_clk`)
- Line 115 uses `rst` as a synchronous reset

Because of line 252, the RX reset can be asserted asynchronously (but asserts synchronous to `rx_clk`).
However, it is routed to `axis_gmii_rx` where it is used on line 250 as a synchronous reset.

# Recommendations for approaching
This issue spans several different modules and is hard to isolate.
Some modules (BRAM) prefer synchronous resets
As far as I know there is nothing that REQUIRES asynchronous resetting, but it is the preferred choice in general
Also note that a small amount of flops in the design have no reset

Currently there seem to be three reset nets in the design: TX reset, RX reset, logic reset (which go under several different names at different parts of the design and are inconsistently used as synchronous or asynchronous).

One approach to identifying where resets are used is to grep the codebase for regex `always(_ff)? ?@ ?\(posedge`:

and look at the sensitivity list to identify asynchronous/synchronous resets. Also note that resets inside the MAC are generally active-high while resets outside the MAC are generally active-low as indicating by the "_n" suffix.

Start by auditing rgmii_phy_if.sv at lines 115 and 252, then inspect axis_gmii_rx at line 250. Use the suggested grep for always_ff/always blocks and sensitivity lists to inventory the TX, RX, and logic reset nets across modules. Done means the reset conventions are consistently applied, including active-high versus active-low usage and modules that require synchronous resets.

Written by the indexing model from the issue text.