Fixes For Accelerator, Diverter, and Target Chamber

[SkeletonAdventure]

I built a linear accelerator, ring accelerator, diverter, and target chamber in a few arrangement in my test world, these are all the fixes that were needed to get those actually working.

• NPE crash when a neighboring accelerator beam port has no live controller
  AcceleratorBeamPortBE/TargetChamberBeamPortBE.extractParticle() called
  targetPort.controller().getCapability(...) without null-checking the
  neighbor's controller (unformed/mid-teardown/unloaded), crashing the
  server. Added the same null guard already used in CreativeParticleSourceBE.

• Ion source capability regression on accelerator controllers
  PARTICLE_HANDLER_CAPABILITY returned LazyOptional.empty() on both Linear
  and Ring accelerator controllers instead of the real particle handler,
  and Ring's getCapability also hardcoded ITEM_HANDLER to empty and
  dropped to empty() instead of super.getCapability() - together these
  blocked ion sources from loading at all. Also fixed ion sources getting
  stuck after their first depletion tick: the depleted stack must be
  written back to the slot unconditionally, since ParticleSourceItem.use()
  returns empty on the exact tick that exhausts the source.

• Target chamber fluid output not being produced
  AbstractRecipe.handleOutputs() only ever inserted item outputs for real
  processing; fluid outputs were computed but never inserted into the
  output tank. Also fixed an off-by-one in
  FluidCapabilityHandler.isValidForOutputSlot() that rejected an output
  exactly filling a tank to capacity, and a
  TargetChamberControllerBE.process() NPE when recipe desynced from
  recipeInfo().recipe() (e.g. after a reload).

• Target chamber fluid tank GUI rendering
  TargetChamberControllerScreen was missing the addWidget() override every
  other screen in the package uses, so fluid tank widgets received events
  but never rendered. Both screens also had the wrong tank index/position
  /size for the two fluid tanks. Also fixed FluidTankRenderer.drawFluid()
  using Math.min(1, capacity) instead of Math.max(1, capacity), which
  clamped the fill level to a sliver for any tank above capacity 1.

• Accelerator redstone port race preventing resume after reload
  Every accelerator_port independently called
  controller().setRedstoneByPort() every tick with no aggregation, so
  whichever port ticked first permanently overwrote the controller's
  redstone state - starving out ports actually wired to a lever. Switched
  from a push model (ports race to write) to a pull model: the controller
  now reads its own signal plus every connected INPUT-mode port's signal
  once per polling cycle and takes the max.

• Same redstone port race in particle chamber ports
  TargetChamberPortBE had the identical flaw, and the write was dead code
  besides: ParticleChamberControllerBE.hasRedstoneSignal() reads a
  shadowed enabledByController field that port writes never touched, so
  port-driven redstone never worked for target/collision/decay chambers.
  hasRedstoneSignal() now also checks every connected INPUT-mode port's
  local signal.

• Ring accelerator bounds resolution corrupted by nearby same-type rings
  resolveRingBounds() disambiguated a ring's outer wall by scanning up to
  64 blocks for any casing block, with no awareness of which physical
  multiblock it belonged to, so a second nearby ring (e.g. a WorldEdit
  copy) could corrupt the resolution and fail validation. Replaced the
  blind scan with an exact positional check once one axis resolves. Also
  fixed errorBlockPos never being set on these failure paths (was
  producing a misleading 0,0,0 in the error message).

• Beam diverter never receiving particles from connected accelerators
  BeamDiverterControllerBE.getCapability() never exposed
  PARTICLE_HANDLER_CAPABILITY, unlike the Linear/Ring accelerator
  controllers, so particle handoff from an accelerator's beam port to the
  diverter silently never happened. Verified in-game: particle now
  correctly hands off ring -> diverter -> second ring.

• StackOverflowError resolving foreign-mod fluid names by string
  IFluidStackIngredientCreator#from(String, int)'s fallback for names not
  in NC's own fluid maps treated any ":" as a full modid:path ID and
  re-entered the same default method via IngredientCreatorAccess.fluid(),
  recursing forever for any third-party fluid (e.g. one registered via
  registerParticleSourceFluid). Reused the existing TagUtil#getFluidByName
  path (already used for bare names) for all names instead.

[igentuman]

Thanks a lot. I will accept the PR. But i disagree on some changes.

• Accelerator/ParticleChamber Controller must not expose capabilities directly. Otherwise we can connect beam line directly to controllers. This also means ports must not call getCapability to controllers, they must pass handlers
• Beam diverter never receiving particles from connected accelerators - this statement seems to be false, because i tested before
• AbstractRecipe.handleOutputs() is a big change, so all multiblocks and processors do output fluids already. Adding this change might cause global issues, need to test and probably apply fix to target chamber specifically