Initialize string cache in context

[raviqqe]

This PR removes the global static string cache that stores CString in MLIR (C++) for each corresponding &str in Rust. Instead, we have a cache in each context. And, that forces users to pass around the new Context type accordingly.

Close #54.

This change is also the base of #271, #23, and #348.

[raviqqe]

@edg-l @Danacus Can any of you review this PR and provide feedback if any?

[Danacus]

Looks good to me! I'm just wondering if you can just use self.context() instead of passing the context as an argument to the methods of Operation? Otherwise it would be possible for users to pass a different Context to the operation, which might have unexpected consequences.

[raviqqe]

I'm just wondering if you can just use self.context() instead of passing the context as an argument to the methods of Operation?

I'm not sure if you are asking if it's possible to add a context field to Operation or if it's possible to use the existing Operation::context() method to fetch the context.

For the former, we can but then we cannot use the Operation values as raw values without explicitly casting. This is problematic when we want to convert an array of Operation values. For example, we won't be able to do &[operation1, operation2] as *MlirOperation.

For the latter, we cannot in general because we use mlirOperationGetContext() under the hood in the Operation::context() method.

Otherwise it would be possible for users to pass a different Context to the operation, which might have unexpected consequences.

I'm thinking of introducing dynamic checks for #271 instead. I think we need those checks anyway to check, for example, if given attributes are from the same context as existing attributes in an operation.

[Danacus]

I meant the latter, but I didn't realize using mlirOperationGetContext cannot be used in general.

[edg-l]

looks good to me!

[raviqqe]

Thank you everyone for reviews!