[Design] Various AXI4 suggestions

While attempting to use `clash-protocols` in a project, I found that the separate type-level records used to represent each of the sub-busses of AXI4 made the library very painful to use. In my [fork](https://git.smart-cactus.org/ben/clash-axi) I have merged these into a [single type-level record](https://git.smart-cactus.org/ben/clash-axi/-/blob/master/src/Clash/Axi4/Config.hs?ref_type=heads#L18); while this is perhaps slightly less principled than the status quo, it is quite a bit less bothersome in practice. Moreover, I think it is quite defensible as one does tend to use at very least all of the read or all of the write sub-busses in conjunction.

Other changes in my fork include:
* Introduction of `HasPortRep` [instances](https://git.smart-cactus.org/ben/clash-axi/-/blob/master/src/Clash/Axi4/ReadAddress.hs?ref_type=heads#L77) for my [`clash-port-name`](https://git.smart-cactus.org/ben/clash-port-name) package, allowing convenient naming of top-level entity ports. With these instances, Vivado's port type inference works without any user intervention.
* Introduced `Address` and `TransactionId` newtypes as these are very frequently needed and have clear semantics
* Reworking the [handling of strobe signals](https://git.smart-cactus.org/ben/clash-axi/-/blob/master/src/Clash/Axi4/Common.hs?ref_type=heads#L99) to support the port naming bits above.
* Introduction of an `Axi4Lite` [type synonym](https://git.smart-cactus.org/ben/clash-axi/-/blob/master/src/Clash/Axi4/Lite.hs?ref_type=heads) and a few smart constructors
* [Various utilities](https://git.smart-cactus.org/ben/clash-axi/-/blob/master/test-utils/src/Clash/Axi4/Lite/Test/Manager.hs?ref_type=heads) for testing designs with my `clash-testbench` [package](https://git.smart-cactus.org/ben/clash-testbench/)

Start by reading the current modules under src/Clash/Axi4/, especially Config.hs, ReadAddress.hs, Common.hs, and Lite.hs, then compare them with the linked fork. Review the test-utils/src/Clash/Axi4/Lite/Test/Manager.hs utilities and existing tests before determining which subset of the proposed API changes can be adopted and how completion should be validated.

Written by the indexing model from the issue text.