[6.x] Fix fieldtypes extending Replicator when adding sets

[joshuablum]

This pull request fixes adding sets to custom fieldtypes that extend Replicator. This worked in Statamic 5, where set defaults were preloaded by Replicator::preload() and inherited by subclasses. #13427 moved this to a request to this endpoint, and #13694 added the handle check that subclasses don't pass, so it has been broken since 6.0.0.

ReplicatorSetController decided whether a field was a replicator by comparing its handle against bard and replicator. A custom fieldtype extending Replicator has its own handle, so it failed that check. The controller then treated the field as something else and threw Undefined array key. Adding a set returned a 500, both when the custom fieldtype was the target field and when the field path went through it to a replicator nested inside.

The controller now resolves the fieldtype from its handle and checks instanceof Replicator, which covers Bard, Replicator and any subclass. A handle with no registered fieldtype is treated as not a replicator, so the existing handling for custom fieldtypes with nested fields still works.