fix: prefer known to unknown lengths in broadcasting

[agoose77]

This PR is a first pass over the broadcasting logic to change direction from "unknown lengths are infectious" to "known lengths are infectious".

As we've discussed here previously, typetracer should only fail for ahead-of-time known errors. We defer validation of the unknown data to runtime, via a second pass using a known-data backend. As such, we can rewrite assertions of the form assert unknown_value == x with unknown_value = x, rather than propagating unknown values everywhere.

i.e. operations like

require_equal_lengths(contents)
next_length = unknown_length

become

require_equal_lengths(contents)
next_length = contents[0].length

I think we might have assumed this before; I'm just getting around to changing the code after re-orienting my thinking a while back.

Relatedly, slicing typetracer arrays should assume that the length succeeds, and use the concrete length, for obvious reason.

[jpivarski]

Yes, "known lengths are infectious" is the right direction: if we try to broadcast length N with length unknown, then the broadcasted result is length N because unknown might be equal to 1. If it's not, we'll find out when a Dask worker tries to actually do it with no unknown lengths.