[PATCH] Introducing initial UseAuto transform

[Vane, Edwin]

  > I'm not sure sugar really matters.

  It does.  `vector<int>::_Iter_type x = ...;` is not valid C++, no matter if it actually compiles on a particular implementation or not.  And transforming non-portable code is asking for trouble.

[REV] Why isn't it valid C++? Is it really our responsibility to test for non-portable code? I understand that by replacing this user-specified type with 'auto' will possibly make code that normally wouldn't compile for some implementations into code that does compile but I think portability testing is beyond scope for the migration tool.  If a user uses an implementation-specific type that makes the code non-portable, should we assume the user did this to make the code non-portable? If the types match while compiling, I would say we can infer the user's intent and use auto and in the process make their code more portable.

  > That said, one could foresee an improvement to this transform that tests for unusual sugar and then prompts the user.

  It can be done easier, I think.  We know that all functions that return iterators have a return value type with correct sugar.  That is, `vector<T>::begin()` return value is always `vector<T>::iterator`.

[REV] This isn't always true. When dealing with for-loops I found from dumping the AST that you don't get vector<T>::iterator but whatever vector<T>::iterator typedefs to which is quite long and complex with libstdc++. It was this realization that prompted the comparison of canonical types.

.  We should desugar the user-provided type until we hit that correct type (then we are sure that the transformation is safe), or we get a canonical type (and that means that the code is unportable).

[REV] I will do some experiments here but given my experience with the aforementioned for-loop issue I expect detecting the 'right type'  as we unsugar isn't going to be easy.