Clean up @sequence

[andrej]

As I'm working on #1610, @jgmelber and me started to come up with a growing list of refactorings and improvements that might make the func.func @sequence in many of our designs better. Let's gather them here.

• Re-use some of the existing syntax for BD configuration on the shim (instead of dma_memcpy_nd). See current proposal.
  • Add parametrizable BD chain syntax and new syntax for BD configuration in sequence #1656
  • Allows re-use of existing BD validation code (e.g. max number of BDs, which currently you can happily specify more than available in hardware in memcpy_nd)
  • Established syntax; users that know BD configuration inside the array will be familiar with the configuration on the shim
  • Proposal allows defining abstract "BD patterns" that can be reused -> less typing, more clarity
• Remove npu prefix from operations that have grown to have lowerings to other backends, e.g. the HSA backend.
• Turn func.func @sequence into its own operation, e.g. aiex.runtime_sequence.
  • Update aiex.runtime_sequence to add optional sym_name, remove unused args #1650
  • We can define the new op to allow capturing SSA values outside its scope, e.g. %tilexx = aie.tile(x, x) that you define in the device, which facilitates the next to-do.
  • Increses clarity -- this is not just a regular function.
  • Removes name ambiguity; while the HSA lowering verifies the function name must be "sequence", for the NPU lowering, NPU instructions from any function will be taken and lowered.
• Make use of existing ops/types for attributes in the shim functions. For example, instead of the column= and row= attributes in aiex.npu.write32, use a tile= argument that takes a TileOp.
  • Allows re-use of existing validation (and other) code for those ops.
  • Improves clarity.