Add precondition that pointers point to structs in the object factory

[antlechner]

I've been trying to find out what kinds of exprts can be passed to the object factory, and in the case of pointers, the only two cases that appeared in the code were pointers to structs and pointers to void*. The latter had a comment saying that it applies to #exception_values, which according to @smowton have been replaced.

I tried adding a precondition that pointers always point to structs, ran most of the tests locally and haven't found any failures yet. So I am assuming that it is now safe to make this change.

I would like to do some refactoring for the struct case in follow-up PRs, so if reviewers think that there is any way that a pointer could still end up in the object factory and point to something other than a struct, please let me know and I will close this PR and instead add a test for this case.

• Each commit message has a non-empty body, explaining why the change was made.
• n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message). [Various existing tests require constructing nondet values in the object factory.]
• n/a My commit message includes data points confirming performance improvements (if claimed).
• n/a My PR is restricted to a single feature or bugfix.
• n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[owen-mc-diffblue]

Assuming CI passes

[allredj]

✔️
Passed Diffblue compatibility checks (cbmc commit: 7cada1b).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/107086687

[allredj]

⚠️
This PR failed Diffblue compatibility checks (cbmc commit: d195cc2).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/107095507
Status will be re-evaluated on next push.
Common spurious failures include: the cbmc commit has disappeared in the mean time (e.g. in a force-push); the author is not in the list of contributors (e.g. first-time contributors); compatibility was already broken by an earlier merge.

[antlechner]

This causes a few test failures in TG, all of which are related to Strings. I will try to reproduce these failures using JBMC and either fix the problem or revert this PR and add a regression test.