Document how structs returned from unconstrained functions can be invalid and need to be checked

[TomAFrench]

See note on #4217

Note that we cannot enforce safety for all types which have validity conditions outside of the type system. e.g. If an unconstrained function returns a U128 then this will not be constrained as its limbs are made up of Fields so no constraints will be applied allowing a potentially invalid value to be returned.

We should ensure that the documentation explicitly calls out the need for users to add these constraints themselves.

[Savio-Sou]

we cannot enforce safety for all types which have validity conditions outside of the type system
👀

As an extension of creating the first admonition with this Issue, we might want to set an example with U128 given it's in the stdlib.

Setting an example in terms of:

1. Implement a check_valid method for U128
2. Add explanations on how the method is implemented and used as an example in the admonition created by this Issue
3. Add a reminder under U128's docs linking to the admonition

[TomAFrench]

To take that a step further, we may want to implement an IsValidInput trait which defined the constraints to be added to a type when it's an input to the circuit (either as an argument to main or as a return value from an unconstrained function). We'd then call this trait implementation whenever we receive this type from outside of the circuit.

For U128 we would range check the two limbs. For BoundedVec we'd assert that the length was consistent with the underlying array, etc.

This would make it much easier for users to consistently enforce that these checks are performed.