RoCC accelerator TileLink manager node interface

**Type of issue**: feature request
**Impact**: API addition (no impact on existing code)
**Development Phase**: proposal

**Other information**
I have a RoCC accelerator that needs to provide a TileLink manager node interface. I enabled this through this simple patch (I know I need to figure out how to correctly specify the currently hard-wired 8 beat-bytes ... sorry about that). I believe this patch is harmless for any RoCC accelerator not using atlSlaveNode.

I know I need to sign the contributor agreement, etc, but I was looking here today to see if this is a viable addition or if there's something about it that's very bad that I may not be considering. My RoCC accelerator has a need to communicate between accelerators over TileLink and that seems to be a very clean way to do it. It's been working well for me, anyway.

```
diff --git a/hw/LazyRoCC.scala b/hw/LazyRoCC.scala
index d58b1f0..25aa865 100644
--- a/hw/LazyRoCC.scala
+++ b/hw/LazyRoCC.scala
@@ -61,6 +61,7 @@ abstract class LazyRoCC(
)(implicit p: Parameters) extends LazyModule {
val module: LazyRoCCModuleImp
val atlNode: TLNode = TLIdentityNode()
+ val atlSlaveNode: TLNode = TLIdentityNode()
val tlNode: TLNode = TLIdentityNode()
}

@@ -74,6 +75,7 @@ trait HasLazyRoCC extends CanHavePTW { this: BaseTile =>
val roccs = p(BuildRoCC).map(_(p))

roccs.map(_.atlNode).foreach { atl => tlMasterXbar.node :=* atl }
+ roccs.map(_.atlSlaveNode).foreach { atlm => connectTLSlave(atlm, 8) } // fix beatBytes!
roccs.map(_.tlNode).foreach { tl => tlOtherMastersNode :=* tl }

nPTWPorts += roccs.map(_.nPTWPorts).sum

```

Start with hw/LazyRoCC.scala and review the existing atlNode and tlNode connections, then inspect how connectTLSlave specifies beatBytes and how other TileLink nodes are wired. Done would require a maintainer-approved API for the RoCC TileLink manager interface, including the beat width and compatibility behavior for existing accelerators.

Written by the indexing model from the issue text.