Fix: Inconsistent type vars in "unbound type var" message

[voodoos]

When upgrading Merlin for 4.14 our test-suite catched the following issue:

class test a c =
object
  method b = c
end

[%%expect{|
Lines 1-4, characters 0-3:
1 | class test a c =
2 | object
3 |   method b = c
4 | end
Error: Some type variables are unbound in this type:
         class test : 'a -> 'b -> object method b : 'b end
       The method b has type 'a where 'a is unbound
|}]

In this example the printed type for method b is inconsistent.
This is due to an extraneous reset of the printer introduced in #10488

This PR add a test illustrating the issue and a fix proposition.

[voodoos]

Hi @Octachron not sure if you are the correct person to ping, sorry if that is not the case :-)
This PR is a very small fix to the printing of some errors, I guess it should be fairly fast to review.
(I can rebase if needed)

[Octachron]

Thanks for the reminder! I have added the PR to my review stack for next week.

[Octachron]

Moving this preparation here makes it a no-op: printer is either Printtyp.class_declaration or Printtyp.cltype_declaration and both of them call Printtyp.reset_context undoing the work done by this call.
Moreover, this matters because there is at least one case where Printtyp.class_declaration does not print itself the method type and thus may not mark cycles which may lead to a stack overflow in the printer(with this PR):

class ['a] c = object method m: (<x:'a; f:'b> as 'b) -> unit = fun _ -> () end
class d = ['a] c

[Octachron]

With the way that the printing classes are wired, I fear that the easiest solution would be to add an optional ?(reset=true) argument to Printtyp.prepare_for_printing and use it in the suberror message printer.

[voodoos]

Ok, thanks for your review and these insights, I will give it more thoughts.

[Octachron]

@voodoos : did you have the time to work on this PR? If not would you mind if I submitted my version of the fix?

[voodoos]

I didn't sadly. Feel free to close this and propose your own :-)

[Octachron]

Superseded by #11609 .