Macros should be all upper-cased. This is also kind of a wart that's
been sticking out for quite a while now (we avoid prefixing
underscores).

Since these button names are printed on all real controllers,
we should show them in the same way as they are printed on
the controllers, regardless of the user's language. It seems
like this was intended all along (except for "Start"), but the
_ markers in TASInputDlg.cpp (accidentally?) led to the button
names in the controller configs also becoming translatable.

I'm making exceptions for "L" and "R" because translators
may want to mark them in some way (for instance "L-Digital")
to clarify the difference from "L-Analog" and "R-Analog".

I'm also making an exception for START/PAUSE because it's
referred to as スタート in Japanese games.

I'm changing "Home" and "Start" to uppercase for consistency
with how Nintendo refers to those buttons, and because someone
who isn't familiar with the Latin script might not know the
connection between the lowercase and uppercase letters (most
users likely do know the connection, but we shouldn't assume it),
and because leaving "Start" as "Start" makes it "collide" with
unrelated strings, such as the string for the button that starts
a netplay session.

To rename "Start" and "Home" without breaking INI
compatibility, I added a ui_name variable like in f5c82ad.

Some strings were marked with _trans in some places but not
others. This commit adds extra _trans markers so that the
usage of _trans is consistent.

This shouldn't have any effect on which strings actually get
translated. (Note that _trans doesn't do anything at runtime.)

I also added a few new i18n comments.

wxQueueEvent/wxPostEvent are useful when the event is being dispatched
to another separate window, but aren't really necessary when the event
will be handled by the same window it's dispatched from.

GetEventHandler() is unnecessary here for the same reason. It's an event
intended to be handled by the dialog itself.

wxCommandEvent already stores the necessary data; the control object
itself doesn't need to be retrieved and casted.

As all UI controls are essentially constructed with new expressions, the
type is already visible on the right-hand side, so repeating the type
twice isn't necessary.