Allow filtering workflows to only running, & add dashboard links

[emma-sg]

Closes #2527

Changes

• Adds backend support for filtering workflows by running state
• Adds "Running" filter alongside "All", "Scheduled", and "No Schedule" options
• Persists filter state in URL search params, allowing for linking to a specific filter
• Updates SearchParamsController with a more flexible API
  • Renames set method to update
  • Adds new set and delete methods that mirror the ones on URLSearchParams
• Adds links to dashboard

Testing

Since this PR involves both frontend and backend changes, you'll need to run the backend locally (or deploy this on dev) to test this out.

1. Start a crawl
2. Navigate to the dashboard. Once the crawl has moved past the "starting" phase, verify that the dashboard shows that there's (at least) one running crawl.
3. Click the "N Crawls Running" text, and verify that it takes you to the crawling page with the "Running" filter selected
4. Click on various other filters (All, Scheduled, etc) and verify that the list updates to match
5. Using your browser's back and forward buttons, verify that the filters update when navigating
6. On an org with more than one page of workflows, verify that you can navigate through multiple pages of workflows and use filters; and that they don't interfere with each other

Screenshots

Workflow List Filter	Dashboard Section

Filters in URLs

[SuaYoo]

Since search params are coupled withthis.filterBy, it should probably be reactive, something like (untested:)

updated(changedProperties) {
  if (changedProperties.has("filterBy")) {
    this.searchParams.delete("page");

    if (this.filterby.schedule) {
      this.searchParams.set("filter", "unscheduled");
      // etc, more logic
    }
  }
}

[emma-sg]

Yeah, I guess that works, but it feels awkward to me, there's a lot of indirection:

  protected updated(
    changedProperties: PropertyValues<this> & Map<string, unknown>,
  ) {
    if (changedProperties.has("filterBy")) {
      this.searchParams.delete("page");
      if (
        this.filterBy.schedule === undefined &&
        this.filterBy.isCrawlRunning === undefined
      ) {
        this.searchParams.delete("filter");
      } else if (
        this.filterBy.schedule === true &&
        this.filterBy.isCrawlRunning === undefined
      ) {
        this.searchParams.set("filter", "scheduled");
      } else if (
        this.filterBy.schedule === false &&
        this.filterBy.isCrawlRunning === undefined
      ) {
        this.searchParams.set("filter", "unscheduled");
      } else if (
        this.filterBy.schedule === undefined &&
        this.filterBy.isCrawlRunning === true
      ) {
        this.searchParams.set("filter", "running");
      }
    }
  }

[SuaYoo]

Maybe this indicates that the search params could be more mappable, something like ?scheduled=true/false, ?running=true/false? Maybe a simplified transformer since setFiltersFromSearchParams feels similarly expanded?

[emma-sg]

I think I found a pretty good solution in 3024f6d — with a more expanded search param schema I'd also want more UI that maps to that, and I think the current setup functions more like presets than it does a full set of filter controls. I'm not opposed to the idea in the future, but I think it'd take a bit more UI design first.

[emma-sg]

On second thought, I think I've come around on this, I do see the benefit when it comes to decoupling UI from stored state a bit more. I took a go at this in e83686b, let me know what you think?