Bind Verilog path with EICG_wrapper

Update Instructions with riscv-opcodes 

configs: add WithHypervisor config

[AXISBundleBits] re-add clonetype override

* AXISBundleBits extends off BundleMap which is of type Record and therefore needs cloneType
* resolves a user issue that can be seen at the repo in this post after compiling the current main's rocket-jar:
* https://stackoverflow.com/questions/72043687/implementing-a-diplomatic-axi-stream-interface-in-chisel-bundlemap-clonetype-e

* git repo: https://github.com/jurevreca12/temp_dspblock_example


* git commit: aca81ab9df437e8cea7fa8abd361b6bab7f40326
* note: replace `lib/rocketchip.jar` with a compiled jar from main
* bug fixed by replacing that rocketchip.jar with the rocketchip.jar generated from the branch in this PR

Signed-off-by: Michael Etzkorn 明凯 <michael-etzkorn@sage.micro.com>

Allow forcing RocketTiles into independent PRCI group

remove objectmodule

Update IncoherentBusTopology to support multiclock and custom cloking

Update Instructions with riscv-opcodes

[Documentation] Note CRC's object explicit+1 notation

Co-authored-by: Jerry Zhao <qwertyuiopghb@gmail.com>

#2963 just so users can follow the CRC object's API a bit better. 


Perhaps #2960 should include a scala doc

Rocket already implemented NMI in #2711,
however, riscv-opcodes currently does not have NMI
as it is a WIP (See https://github.com/riscv/riscv-opcodes/pull/67)

To avoid generating Instructions.scala from a patched riscv-opcodes,
putting NMI related insts/CSRs into CustomInstructions is reasonable.

As standard instructions are synced from riscv-opcodes

The current Instructions.scala is not up-to-date with riscv-opcodes

Previous changes on this file seems to be adding new instructions manually,
this can be inferred from
https://github.com/riscv/riscv-opcodes/commit/e2ebbf53340bd856cde5eabfaa6b15831c791478
which changed the name from parse-opcodes to parse_opcodes
thus this PR reorders a lot of instructions and CSRs

Co-authored-by: Jerry Zhao <qwertyuiopghb@gmail.com>

This currently has no functional implications, but will be necessary
after improvements to DecodeLogic.

Update from running new version of Scalafix

Avoid unnecessarily stalling integer instructions that access an x
register whose numeric specifier coincides with the f register
destination of an earlier floating-point instruction.