Make `Fig.Generator["trigger"]` more declarative

Sanity checks

• I have searched github.com/withfig/fig/issues and there are no duplicates of my feature

Feature Details

There are some things that currently happen imperatively that could happen declaratively.

• Token length changes
• Token length changes around a number, eg for 5: from 4>5, 4>6, 6>5, 6>4, etc.
• Final index of one of N strings is changed, instead of just one

type Trigger =
  | string
  | ((newToken: string, oldToken: string) => boolean)
  | { on: "change" }
  | { on: "threshold"; length: number }
  | { on: "string"; string: string | string[] };

interface Generator {
  trigger: Trigger;
}

const _0: Generator = {
  // Trigger on every keystroke
  trigger: { on: "change" },
}

const _1: Generator = {
  // Trigger when length passes 5
  trigger: { on: "threshold", length: 5 },
}

const _2: Generator = {
  // Trigger when length changes to or from 0
  trigger: { on: "threshold", length: 0 },
}

const _3: Generator = {
  // Trigger when any of the last index of any of the strings are changed
  trigger: { on: "string", string: [":", ","] },
}

// Implementation / equivalent `trigger` functions

// change:
// () => true

// threshold:
// (curr, prev) => (curr.length <= length && prev.length >= length) || (curr.length >= length && prev.length <= length)

// string:
// (curr, prev) => Math.max(...makeArray(strings).map((string) => curr.lastIndexOf(string))) !== Math.max(...makeArray(strings).map((string) => prev.lastIndexOf(string)))

cc @fedeci - are there any extras you can think of? Better names? I think this covers the main use-cases.

[fedeci]

type Trigger =
  | string
  | ((newToken: string, oldToken: string) => boolean)
  | { on: "change" }
  | { on: "threshold"; length: number }
  | { on: "match"; string: string | string[] };

I think this is a better naming, and I like the idea of having a sugar on top of trigger.

[SeparateRecords]

Definitely wouldn’t remove the ability to use a function, but making it simpler to do the most common things is good

Just checked in withfig/autocomplete and this covers almost every case where there’s currently a function for trigger