Make sure type conversion materialization callbacks return values of the correct type

[maerhart]

The materialization callbacks have to return either a nullopt or a value of the type provided as argument. This is not guaranteed by the ones changed in this PR.
This callback is invoked when an unrealized_conversion_cast operation inserted by the dialect conversion framework cannot be reconciled by the framework itself (e.g., if the input and output types of the op match, it gets folded away automatically).
This PR takes the conservative route, just telling the dialect conversion framework that it is fine to leave the conversion cast op in there if it cannot get rid of it. We could also return nullopt to tell it that it should fail in those cases.

[uenoku]

LGTM, thank you for taking care of Conversion framework. This matches what upstream code usually does.

[dtzSiFive]

The comment above this says the materialization here is to fold away the casts, which seems unlikely to be what is accomplished by the new version.

Should this just be dropped? (And the other here?)
(I can help answer that later)

Thanks for helping maintain this!

[maerhart]

Right, it is also not what is accomplished by the old version. Let me change that comment to make clear what it does.

[maerhart]

Note: once the next LLVM bump has landed, some passes can remove their add{Target,Source}Materialization callbacks and use the buildMaterializations = false ConversionConfig (only if all the callbacks only insert an unrealized_conversion_cast).
I'll leave this for another PR(s) because it's just a cleanup, and each pass needs to be checked to see whether this applies.