[Feature Request] Re-enable `ConvertibleToPython` conformance for builtin types

Review Mojo's priorities

• I have read the roadmap and priorities and I believe this request falls within the priorities.

What is your request?

Re-enabling ConvertibleToPython conformance for builtin types allows them to be used in generic code depending on ConvertibleToPython conformance.

What is your motivation for this change?

This was discussed on Discord with Chris and others.
https://discord.com/channels/1087530497313357884/1503501113217781810

It is appealing to me because it is cleaner and less arbitrary, but it does mix more python stuff into standard files. It is probably the cleanest solution though.
All this stuff will be much cleaner with extensions! 🙂
In any case, I support # 2 if you think this would help. Would you be willing to put up a PR?

Changes:

• Remove implicit init methods on PythonObject for the builtin types (Bool, Int, Skalar, StringLiteral, StringSlice and String).
• Add trait ConvertibleToPython to those types. This still allows for implicit conversion to PythonObject.
• Add unit tests to check ConvertibleToPython conformance and implicit conversion
• Aligns builtin types with custom types as both use the same implicit PythonObject init method.

As discussed with Chris I will open a PR for this change.

Any other details?

This is related to [mojo-stdlib] 3/x: Continue simplifying PythonObject implementation · modular/modular@5a23c2a where conformance to ConvertibleToPython was removed from builtin types to enable implicit conversion to PythonObject for custom types conforming to ConvertibleToPython.

Start by locating the builtin type definitions for Bool, Int, Skalar, StringLiteral, StringSlice, and String, along with the PythonObject and ConvertibleToPython implementations. Review the related unit-test area before making changes. Done means the listed types conform to ConvertibleToPython, implicit PythonObject conversion remains covered, and the unit tests pass.