[SPARK-24268][SQL] Use datatype.catalogString in error messages

[mgaido91]

What changes were proposed in this pull request?

As stated in #21321, in the error messages we should use catalogString. This is not the case, as SPARK-22893 used simpleString in order to have the same representation everywhere and it missed some places.

The PR unifies the messages using alway the catalogString representation of the dataTypes in the messages.

How was this patch tested?

existing/modified UTs

[mgaido91]

cc @gatorsmile @HyukjinKwon

[SparkQA]

Test build #93236 has finished for PR 21804 at commit eb78665.

• This patch fails Scala style tests.
• This patch merges cleanly.
• This patch adds no public classes.

[SparkQA]

Test build #93237 has finished for PR 21804 at commit aeb1766.

• This patch fails to build.
• This patch merges cleanly.
• This patch adds no public classes.

[SparkQA]

Test build #93252 has finished for PR 21804 at commit 5ffc793.

• This patch fails Spark unit tests.
• This patch merges cleanly.
• This patch adds no public classes.

[maropu]

(This is just a question...) Is it ok for some types to have private[spark] and the others to have private[sql]? I feel a little inconsistent policy for that. Since the other components (e.g., ml and mllib) depend on the sql type system, is it bad to make all the modifiers in their types private[spark] consistently?

[mgaido91]

I am fine changing them all to private[spark]. @gatorsmile @HyukjinKwon what do you think?

[HyukjinKwon]

To me, let's leave them out for now, and fix or discuss when the change is actually needed later.

[SparkQA]

Test build #93276 has finished for PR 21804 at commit 3c8eb98.

• This patch fails Spark unit tests.
• This patch merges cleanly.
• This patch adds no public classes.

[SparkQA]

Test build #93285 has finished for PR 21804 at commit 20ee744.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[gatorsmile]

LGTM

Thanks! Merged to master.