Fix #235 allocatable classes

[krystophny]

Fixes #235 . This PR sits on top of #230, #231, #232, #237, #238 and #239.

[krystophny]

@jameskermode this PR is ready for a full review and merge. @Rykath, @Xyhlon - please also have a look and comment if you see something odd.

The code now

1. Wraps all objects that are used as a class anywhere into another wrapper type.
2. Allows to access member variables of classes via this nested type structure.
3. Adds an extra allocate in the auto-generated constructor for the inner object
4. Skips explicit call to the final procedure in the destructor, as this is done automatically via deallocate. The previous behavior was most likely a bug.

The solution involves adding a used_as_class attribute. This requires traversing the parse tree another time in find_types, as the usage via class is defined in procedures after types are already known.

The change is significant, as the wrapper type is introduced also in cases that were previously handled with type alone even though class appeared, e.g. examples/arrays_in_derived_types_issue50. I believe the behavior is now more consistent, and all test cases pass after the change. Still, one may also test with some real-world downstream codes before a release.

[krystophny]

@jameskermode could you already take a look at this PR? In the meantime we could finish also #233 to fix #41 on top of this.

PS: Tests are passing, but the "Build wheel" jobs are causing troubles and I don't understand why.

[jameskermode]

Thanks very much for this contribution. As you say it's a major chance so will need testing with some downstream codes wrapped with f90wrap to ensure there are no regressions not captured in the unit tests. I should have time to do that next week. Do I understand right that this PR should be merged before #233?

[krystophny]

Sure! For now the main work is done and there is no hurry. You are right, #233 should be merged after this one. We will also be testing on our fork on https://github.com/itpplasma with some of our codes in the meantime. With #233, f90wrap will cover all the remaining requirements for interfacing modern code from a compiled language in Python with minimal effort (C++/pybind11 people already envy us now).

[krystophny]

... or if you have time for a short videocall to discuss some points directly, just drop me an e-mail then.