* Exclude archived collections from tree view

This is a bit more nuanced that it might first appear. The bug report is
the permissions editor for collections is showing child collections
which are archived. But the api sends back ALL collections, regardless
of archival state. So the FE knows to omit top-level archived
collections but not archived child collections.

So we thought about just having the FE remove all archived ones, but
best to remove it from the response. One worry is that we're not sure if
any callers want archived collections in the tree view or not. So right
now they are removed with a `?exclude-archived=true` query param, but if
we can demonstrate that no callers of the tree api ever want archived
items we can make this the behavior, rather than an optional behavior.

To verify that the tree api is sending back all collections, you can
check

```clj
collection=> (collection/collections->tree
               {}
               [{:archived false
                 :name "foo"
                 :id 1
                 :location "/"}
                {:archived true
                 :name "foo"
                 :id 2
                 :location "/1/"}
                {:archived true
                 :name "its archived"
                 :location "/"
                 :id 3}])
;; we have always sent back archived collections, both top level and children
({:archived false,
  :name "foo",
  :id 1,
  :location "/",
  :children ({:archived true,
              :name "foo",
              :id 2,
              :location "/1/",
              :children ()})}
 {:archived true,
  :name "its archived",
  :location "/",
  :id 3,
  :children ()})
```

* hide archived collections from the collections permissions page (#19616)

* fix incorrect issue number

Co-authored-by: Alexander Lesnenko <alxnddr@users.noreply.github.com>
Co-authored-by: Aleksandr Lesnenko <alxnddr@gmail.com>

* Hide table popover based on a few conditions

* fix TS id type inference

* use util fn

Pursuant to the nits from #18678 and #18676

This actually has nothing to do with waterfalls. Really, it's that static viz is brutally incompatible with bignum types, bigint and bigdec. However, nothing will fit in the screen anyways if you actually need a bignum or bigint type so the solution was to just coerce and be OK with exploding if it actually needed bignum range.

* add delay prop to table/dimension info popovers

* move isCypressActive delay check to TippyPopover

Seems that the very first focus happens when the element ref isn't ready
yet (the component did not completely get mounted).

* simplify nav options [ci skip]

* icon tweaks [ci skip]

* dismiss when clicking items [ci skip]

* lint

* Prototype/create button (#19587)

* fix create menu not closing

* update specs

* lint

* fix more specs

* fix specs

* specs

* clean up

* specs

Co-authored-by: Alexander Lesnenko <alxnddr@users.noreply.github.com>
Co-authored-by: Aleksandr Lesnenko <alxnddr@gmail.com>

* don't try to show number fingerprint for ID fields

* add repro

* Allow override of WEEK_START in Snowflake driver

Incorporate the following sources of WEEK_START, in decreasing order of precedence:
1) the connection string, a.k.a. additional-options (ex: WEEK_START=N)
2) the Metabase "start-of-week" setting (i.e. day of a week)
3) the default value (7: Sunday)

Adding new fn to the driver.common namespace to parse a connection string param out of additional-settings (plus a test for that)

Adding Snowflake driver test to ensure that all cases above are covered as expected, by invoking the DAYOFWEEK function on a set of fixed dates

Update documentation for start-of-week setting to clarify that it now influences this behavior

Swap out parse-additional-options-value for additional-options->map instead (more generic)

Update test accordingly

* downgrade cypress to 6.4

* add resolution to cypress 6.4.0

* docs - qb screenshots

* updated screenshot

* docs - replaced screenshots

The previous Chevrotain-based parser had a few limitations, which need
to be taken account by the expression generator for the fuzzer. With the
new recursive parser (PR #19335), these limitations are not necessary
anymore:

* leading decimal digit, e.g. `.25`
* nested negatives, e.g. `-- 3`
* nested boolean NOT, e.g. `NOT NOT X`

If the expression is not valid, i.e. there is an error message
associated with processing it, do not blindly continue with it, since it
leads to a potential rewrite of the expression (the rest of
the parser/compiler can tolerate certain brokenness).