Deprecate Texinfo commands

[Gavin Smith]

I'd like to suggest that some Texinfo commands could be marked as
deprecated, with warnings could be introduced to encourage people to
remove these commands from their documents/config files.  Some rarely
used commands could possibly even be removed at some point in the
future.

@definfoenclose.  I believe that this is used by Sphinx, so can't
be removed immediately, but there is no real use for it.  It was
originally introduced for the Jargon File which wanted to be able
to customize the Info output.  This kind of output format-specific
command doesn't fit in with the other commands in Texinfo which are
"semantic" and format-general.  It's an obscure way to create a new
Texinfo command but one which does add some complexity to parsing
Texinfo.  I'd be happy if this one went.

@smallexample and friends.  Simpler to use @example instead.  If people
desperately want to use smaller fonts in the printed output they
could use

@set dispenvsize small

instead, which is only used by texinfo.tex and doesn't affect anything
else.

@acronym.  gnulib warns about use of @acronym (in top/maint.mk),
the manual does not encourage it, and <acronym> has been removed from
recent HTML standards.

@refill.  Does nothing.

My guess is that @smallexample, @acronym and @refill should continue
to be supported for compatibility with old documents that use them.

@rmacro.  I'd have to check but I believe that @macro can also be used
recursively.  I doubt that this is much used.

@setcontentsaftertitlepage and @setshortcontentsaftertitlepage
are already marked as deprecated and do nothing.  I suspect that
these aren't used much and could probably be removed.

@inforef: Little need for this as Info files are nearly always generated
from Texinfo source.

There are other commands like @exampleindent or @clickstyle which
are used for customizing the output, which is not ideal, but in the
absence of an alternative I suppose they should be kept.

I think @t, @i, @b and @raggedright should be kept as they are; even
if they are "non-semantic", they are harmless, and may occasionally
be useful.  I'm not sure about @sp.