java: push: do not reset the error counter

* data/lalr1.java (parse): here, when in push-pull is in "both" mode.
This breaks the test suite, for instance
make check TESTSUITEFLAGS='-d 388 BISON_USE_PUSH_FOR_PULL=1'.
More generally make maintainer-push-check.
style: minor changes in the Java tests

* tests/java.at (AT_CHECK_JAVA_GREP): Ignore the exit status.
* tests/javapush.at (AT_CHECK_JAVA_GREP): Be more alike the previous
one.
Formating changes.
Remove stray debugging "jj" file.
tests: fix Java push failure when running with BISON_USE_PUSH_FOR_PULL

* tests/javapush.at (Trivial Push Parser with api.push-pull verification):
When push for pull is enabled, there is one such function generated.
java: rename YYMORE as YYPUSH_MORE for consistency with C

http://lists.gnu.org/archive/html/bison-patches/2013-06/msg00008.html

* data/lalr1.java, doc/bison.texi, tests/javapush.at:
s/YYMORE/YYPUSH_MORE.
NEWS: prepare for 2.7.91

* NEWS (2.7.91): Java push parsers.
version 2.7.91

* NEWS: Record release date.
maint: post-release administrivia

* NEWS: Add header line for next release.
* .prev-version: Record previous version.
* cfg.mk (old_NEWS_hash): Auto-update.
tests: fix 'find' portability issues

Reported by Stefano Lattarini.
http://lists.gnu.org/archive/html/bug-bison/2013-06/msg00000.html

* tests/output.at (AT_CHECK_OUTPUT): Use Perl instead.
tests: skip C++ tests if we can't compile a simple program

There are possible conflicts between gnulib replacement functions (in
<stdio.h>) and their C++ wrappers (in <stream>).  Trying to address
these in configure seems too hard, and I don't know how to fix the issue
in gnulib.  Cowardly avoid the problem by skipping C++ tests when this
happens.
Reported by Stefano Lattarini.
http://lists.gnu.org/archive/html/bug-bison/2013-06/msg00001.html

* tests/atlocal.in (BISON_CXX_WORKS): Also set it to "skip" if we can't
compile a simple program using <stream>.
* tests/local.at: Comment changes.
gnulib: update
yacc: beware of "uninitialized uses" warnings

Again some issues with the fact that yylval is reported by GCC as
possibly not initialized in some cases.  Here, the case at hand is the
%destructor.

I am still not convinced that it is worth going all the trouble of
using pragmas to disable temporarily some warnings, instead of just
initializing the looking symbol once for all, but that's what Paul
voted for, see
<http://lists.gnu.org/archive/html/bison-patches/2012-10/msg00050.html>.

* data/c.m4 (b4_attribute_define): Define
YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN, YY_IGNORE_MAYBE_UNINITIALIZED_END,
YY_INITIAL_VALUE here, as we will need them in the generation of the
destructor function, which is defined in yacc.c before yyparse, which
was in charge of defining these macros.
* data/yacc.c (b4_declare_scanner_communication_variables): Simplify:
trying to factor the definitions of the case pure and impure is
too complex.
Actually, it is not even clear that this macro should really exist,
as even the calls are complex.
Be careful not to issue a lone ";", as this is a statement, and C90
forbids declarations after statements ; so write
"YY_INITIAL_VALUE(Decl;)", not "YY_INITIAL_VALUE(Decl);".