Suggest to open Bigarray when using its indexing operators.

[alainfrisch]

This PR implements the proposal from http://caml.inria.fr/mantis/view.php?id=6765 . Now that .{}-like operators are user-definable, one needs to explicitly open Bigarray. To help with the transition, this PR adapts the "Unbound value" error printer to suggest opening Bigarray.

If #248 is accepted, one should change the text of the suggestion.

Note that on Mantis, it was also discussed to add a hack to automatically lookup those operators in Bigarray and issue a warning. Perhaps we should accept the patch there and keep this PR for later (when the hack is removed).

[Octachron]

Personnally, I am rather in favor of the temporary lookup hack for 4.03 and then a transition to an error and a custom warning next version. It could make the transition smoother than going directly to an error.
I would try to submit on github my updated patch for the temporary hack tonight.

However, a problem with both patchs is that the error message is not entirely convincing: should you recommend to open the bigarray module directly? There was sensible complaints in mantis:6765 and #248 that opening the Bigarray module is not good practice and should not be encouraged.

Maybe it would make more sense to also link the relevant section of the reference manual for a more detailled explanation of what is going on?

[gasche]

The current plan is to not include #69 in the next release, making this one unnecessary, so I will close it to facilitate triaging. I do plan to keep #69 available in a branch, and in this branch we should also apply the "temporary lookup hack" that we decided to have for backward-compatibility (before making the revert decision). So Pull Requests to implement this are warmly welcome. (I think I'll also include the module Operators = ... PR in this branch.

[Octachron]

I like the idea of integrating the operators submodule patch in the branch: it makes both the documentation and the deprecation warning cleaner. I will submit a pull request to implement the temporary deprecation warning once there is a clear place to do so. As an alternative possibility, I could also merge both commits in #69 after the reversion.

[gasche]

While we're at it, another thing not to forget is to revert your (excellent) documentation patch for indexing operators. I looks like #302 is progressing faster than I expected, so I'll wait for it to be merged and put #69 and ocaml/ocaml-manual#8 in the same branch (easier than having two related branches in two distinct repositories).