Use explicit item type map to determine field types and encodings

[piehld]

This PR is intended to address a current limitation in the conversion of mmCIF to BCIF for some data items.

Specifically, there's a bug when handling some uncommon data types such as point_group and float_range.

• point_group fails because it has "int" in the name (i.e., "point_group")
• float_range fails because it has "float" in the name, so the code tries to encode it as a float, but really it's a string since the value contains a hyphen

Rather than having the code try to figure out what the type is and how to encode it based on substring matching, I've added a [current] complete list of possible types and what they should be encoded as. This is similar to the method being used by our Java encoder (e.g., see here).

Additionally, I made a minor adjustment to the __molstar_forced_ints object, in which I changed it to be a dictionary rather than a list to allow for O(1) efficiency.

[epeisach]

Okay - your code rolled back som submodules -- hence tests failing.

Is there a reason you are doing this?

Otherwise - fundamentally looks good...

[epeisach]

I notice that you are using the term "field" in inMostarTypeHints -- maybe use the term "name" -- this would be consistent with PdbxContainers.py CifName class.

[epeisach]

I reverted back the modules/cpp-cif-file to latest.
(git submodule update after you pull in changes to your branch)

I leave it to you to decide "field" vs "name" discussion.

[epeisach]

You mentioned that this was detected by trying to convert public PDB files. Perhaps a test case to show success? I am not sure what the failure mode was with existing code and if it was detectable. Or create a simple test script that outputs a minimal file - with point_group in it - and show it works - which would have failed before?

[epeisach]

I have added a test - that would ail with current code and is fixed with your changes. I needed to capture the output of logging and look for the cast error - which is no longer present.