mysql db may get duplicated index c_problem_2 for "problem" table

This is followup of ZBX-12758, you can find more details in last comment.
The change in 3.4.6 has added an index create index problem_3 on problem (r_eventid), schema.tmpl was updated too.

Background:
"problem" table, introduced in 3.2, has c_problem_2 constraint, which automatically adds an `c_problem_2` (`r_eventid`) index on MySQL db backend.

What interesting I discovered is:
if zabbix database was existing from a moment, when "problem" table was created together with the constraint, then the existing index c_problem_2 will be magically "renamed" to problem_2, which is attempted to be created.

But, if once after upgrade to 3.2, I had to dump and restore my zabbix database - the attempt to create the new index will be done "as is", and I'll get two identical indexes - c_problem_2 and problem_2.
This is not very good.

It's suggested to improve the patch logic to in a way to rename existing index.
And probably remove the c_problem_2 index for those, who already upgraded to 3.4.6.