refactor(assert): prepare for noUncheckedIndexedAccess

[syhol]

Handling all noUncheckedIndexedAccess issues for the assert module, tracked in #4040

[syhol]

I feel a bit unsure about this one. We can't say for certain if these indices are correct as it's all dependent on if routes was built correctly.

[iuioiua]

I'm unsure what to do here too. @kt3k, WDYT?

[kt3k]

diff is hugely used across Deno ecosystem (via assertEquals). I don't think this includes such basic bugs. I think it's fine to use non null assertion here.

[syhol]

Best to review this as 4 separate bits:

• createCommon: small and simple
• backTrace: small risk but ultimately ignoring with !
• createFP / snake / ensureDefined / the bits where currentFP is used: this was a messy situation and the types were lying, now marking FarthestPoint as being possibly undefined in more places, and needing to handle new cases of missing values.
• diffstr (tokenize / createDetails): a few new consts and type tweaks, nothing crazy

[syhol]

Changing

function (
    slide: FarthestPoint | undefined,
    down: FarthestPoint | undefined,
    foo: any,
) {}

to

function (
    slide?: FarthestPoint,
    down?: FarthestPoint,
    foo: any,
) {}

is causing the error:

A required parameter cannot follow an optional parameter.deno-ts(1016)

Options are:

1. Revert it back to FarthestPoint | undefined
2. Move the optional parameters to the end of the parameter list

Personally I prefer option 1 as we never expect to call the function without those parameters. I'll revert it for now but happy to change to option 2 if you wish.

[syhol]

Waiting on #4074 to get checks to pass

[iuioiua]

Changing

function (
    slide: FarthestPoint | undefined,
    down: FarthestPoint | undefined,
    foo: any,
) {}

to

function (
    slide?: FarthestPoint,
    down?: FarthestPoint,
    foo: any,
) {}

is causing the error:

A required parameter cannot follow an optional parameter.deno-ts(1016)

Options are:

1. Revert it back to FarthestPoint | undefined
2. Move the optional parameters to the end of the parameter list

Personally I prefer option 1 as we never expect to call the function without those parameters. I'll revert it for now but happy to change to option 2 if you wish.

Let's do number 1.

[syhol]

Let's do number 1.

Great, thats already applied as of 8aedb7c

[kt3k]

LGTM

[iuioiua]

LGTM too