[GlobalOpt][Flow][Quant] Fix segfault on unlowered quant.uniform types

[FedericoBruzzone]

HoistIntoGlobalsPass's HoistableTensorTypeInterface unconditionally called getIntOrFloatBitWidth() on a tensor's element type to decide whether it is hoistable, assuming it is always a plain int/float. A !quant.uniform<...> element type is neither, so getIntOrFloatBitWidth() crashes instead of returning a sane answer.

isHoistableType/isHoistableLeafType, with this PR, check that the element type is actually an int/float
before computing its bit width via a new helper hasComputableBitWidth, and conservatively treat anything else as
non-hoistable.

Additonally, quant.uniform types leak into the pipeline because quant is a transitive type dependency of TOSA, not because we have any lowering support for quant.qcast/quant.dcast/quant.scast AFAIK. TOSA's own conversion to linalg/arith is expected to fully resolve these before Flow. VerifyInputLegalityPass already enforces that for those some dialects, quant was simply missing from the list, so IR where these ops survive past GlobalOptimization would segfault later.

Fixes #24814

[AGindinson]

Thanks @FedericoBruzzone, I'll give this a proper look tomorrow! Reminded me of my stale PR #22920 which was aiming to address another (narrower?) case, and ultimately I haven't found a good direction upon an apt review comment from Mahesh.

[FedericoBruzzone]

Hi @AGindinson! As always, thank you so much. There's no rush 🫶

Tomorrow or later, I'll take a look at your PR to get an idea of what it's about. Sorry, but I didn't have a chance to do that before sending this (I didn't know it existed).

EDIT: Unfortunately, at first glance, I don't think this PR will help #22920. This PR aims to maintain a conservative approach when working with statically unknown size types (i.e., we consider only int and float).

[FedericoBruzzone]

Are CI's failures related to this PR? 🤔

[AGindinson]

@FedericoBruzzone Not sure what the Bazel issue is about, but doesn't seem to be the case on other PRs/on main. Could you maybe rebase?

[FedericoBruzzone]

@AGindinson, thanks for checking it out!
I think I fixed the problem in the latest commit :'D