More fully describe datatypes

[ZacLN]

This PR picks up a fair bit of information that is not currently stored:

• A mirrored type-system is created. This allows proper representation of types through out the symbol-stores. For example, we now have full type information for method arguments.
• No need for the duplication of show methods (this was causing crashes where faulty show methods for package datatypes had been defined).
• Return types for methods - would allow us to do more interesting inference stuff.

On the down side:

• Getting return types for methods requires the compilation of everything - time consuming. Caching in the cloud (#108) will probably be necessary to make this acceptable for the avg user (calculation of return types could be disabled in the short term.)

@davidanthoff, this is more for discussion than immediate merge as changes would across the languagesever/statliclint setup

[davidanthoff]

Cool! This also generally means that we are using our own types to represent all of this, which might make it easier to switch the cache file format to say some JSON thing, right? If we do want to go in the cloud direction, then using a file format that is not serialization is probably something we'll have to do... Would also help with the idea to compile the whole LS.

I don't understand the return type part for methods :) How would we decide for which input types we compute return types?

[ZacLN]

This is ready now (+ SS/LS relevant PRs). On the return types - this is disabled for now (too time consuming). Use of return types would require a bit on inference our side (i.e. sin(1.0)::Float64 as a really simple example)

Note: this is breaking

[ZacLN]

Yep, sounds good