Colliding module name: ALU

**Type of issue**: bug report

**Impact**: API modification

**Development Phase**: request

**Other information**
When running

litex-boards/litex_boards/targets/sipeed_tang_primer_20k.py --build --cpu-type rocket --cpu-variant linux --cpu-num-cores 1 --cpu-mem-width 2 --sys-clk-freq 50e6 --with-ethernet --with-sdcard --toolchain=apicula

it turns out that Yosys and Gowin already have an ALU module which collides with the Rocket Chip ALU
moving the file from src/main/scala/rocket/ALU.scala to src/main/scala/rocket/RocketALU.scala and renaming all it's occurrences makes Yosys finally run through and arrive at nextpnr-himbaechel

**If the current behavior is a bug, please provide the steps to reproduce the problem:**

Running litex-boards/litex_boards/targets/sipeed_tang_primer_20k.py --build --cpu-type rocket --cpu-variant linux --cpu-num-cores 1 --cpu-mem-width 2 --sys-clk-freq 50e6 --with-ethernet --with-sdcard --toolchain=apicula

**What is the current behavior?**

Synthesis for Gowin boards with Yosys fails

**What is the expected behavior?**

That the synthesis runs through and the follow up tools like nextpnr can generate a bitstream and I can run a RISC-V SoC on my FPGA

**Please tell us about your environment:**

openSUSE Tumbleweed

**What is the use case for changing the behavior?**

Using Rocket Chip with Litex on my Sipeed FPGA from Taobao

Start with src/main/scala/rocket/ALU.scala and search the Rocket Chip sources for references to the ALU module. Rename the module and its occurrences as described, then rerun the supplied Sipeed Tang Primer 20K build command with the Apicula toolchain. Done means Yosys completes synthesis and the flow reaches nextpnr-himbaechel.

Written by the indexing model from the issue text.