Refactor Queue with dataview+Definition/instance API

**Type of issue**: feature request

**Impact**: API modification

**Development Phase**: proposal

**What is the current behavior?**
A lot of queue will be generated in a large-scale design, which was known as the `Queue` issue in rocketchip.

**What is the expected behavior?**
Trying to use the new feature in Chisel 3.5 to resolve this. Only generate one module for each same queue.
Like what I did in the #2250, I’d like to refactor queue with definition/instance api to cache queue with same parameter.
However the problem is Queue Module consumes Chisel data type as a type parameter which makes this impossible to implement, since it’s each queue almost has different type parameters.
But actually queue didn’t use the chisel type parameter, it only use which to do the sanity check inside queue, which is not related to the real queue hardware implementation.
Thus I’d like to propose a API breaking change to move those changes out from Queue Module, while provide a same user interface via dataview API.
This will break `new Queue(…)` API.
But the Queue factory will remain the same.

**Please tell us about your environment:**
- version: `3.5-SNAPSHOT`
**What is the use case for changing the behavior?**
Optimize the generated verilog code to use less Queue Module, and speed up elaborate pass a little, as well as dedup pass.

Start by reviewing Queue and the related #2250 changes, then read the Chisel 3.5 dataview and Definition/instance APIs. Establish the caching and API behavior needed to share one generated queue module for identical parameters while preserving the Queue factory and moving type-based sanity checks out of the module. Confirm the resulting generated Verilog and elaboration behavior.

Written by the indexing model from the issue text.