i3c_controller: Remove CLK_MOD, set SDA low at Stop, add address width parameters

[gastmaier]

PR Description

Running the core at 50MHz, even though works, provide worst performance and improper stall times.
The target carrier, DE10Nano, can be configured to provide a clk near 100MHz without using a PLL.
Therefore, remove this option and require 100MHz input clock. Also, simplify logic to hold SDA lane always to ground during the bit, avoiding conditions where SDA rises before SCL, not yielding a proper stop bit.

Add address width parameters, because these values affect considerably the resource utilization, therefore, make them user-configurable.

non-sticky interrupt pending
Set interrupt pending on source signal rising edge, to allow clearing
it and then resolving, e.g.:

  static irqreturn_t adi_i3c_controller_irq(int irq, void *data)
  {
          struct adi_i3c_controller *controller = data;
          u32 pending;

          pending = readl_relaxed(controller->regs + REG_IRQ_PENDING);
          writel_relaxed(pending, controller->regs + REG_IRQ_PENDING);
          if (pending & IRQ_PENDING_CMDR_PENDING) {
                  spin_lock(&controller->xferqueue.lock);
                  adi_i3c_controller_end_xfer_locked(controller, pending);
                  spin_unlock(&controller->xferqueue.lock);
          }
          if (pending & IRQ_PENDING_IBI_PENDING)
                  adi_i3c_controller_demux_ibis(controller);
          if (pending & IRQ_PENDING_DAA_PENDING)
                  adi_i3c_controller_handle_da_req(controller);

          return IRQ_HANDLED;
  }

Breaking change because removes an user set parameter.

This was tested on hardware by me and a third-party

PR Type

• Bug fix (change that fixes an issue)
• New feature (change that adds new functionality)
• Breaking change (has dependencies in other repos or will cause CI to fail)
• Documentation

PR Checklist

• I have followed the code style guidelines
• I have performed a self-review of changes
• I have compiled all hdl projects and libraries affected by this PR
• I have tested in hardware affected projects, at least on relevant boards
• I have commented my code, at least hard-to-understand parts
• I have signed off all commits from this PR
• I have updated the documentation (wiki pages, ReadMe files, Copyright etc)
• I have not introduced new Warnings/Critical Warnings on compilation
• I have added new hdl testbenches or updated existing ones