[8u] HotSpot build assumes ENABLE_JFR is set to either true or false

With the JFR backport to 8u (JDK-8223147), the HotSpot build introduced conditionals depending on the value of ENABLE_JFR.

The conditionals assume that ENABLE_JFR is always set, either to true or false. This is true when the Makefiles are invoked using confgure & spec.gmk, but nothing in the HotSpot build sets it. Thus, when the HotSpot build is used in isolation, the build fails:

In file included from /home/ahughes/builder/icedtea8-shenandoah/openjdk-boot/hotspot/src/share/vm/jfr/leakprofiler/checkpoint/eventEmitter.cpp:31:
/home/ahughes/builder/icedtea8-shenandoah/openjdk-boot/hotspot/src/share/vm/jfr/leakprofiler/sampling/objectSample.hpp: In member function 'bool ObjectSample::is_alive_and_older_than(jlong) const':
/home/ahughes/builder/icedtea8-shenandoah/openjdk-boot/hotspot/src/share/vm/jfr/leakprofiler/sampling/objectSample.hpp:211:24: error
: 'const Ticks' {aka 'const class TimeInstant<CounterRepresentation, ElapsedCounterSource>'} has no member named 'ft_value'; did you
 mean 'value'?
       _allocation_time.ft_value() : _allocation_time.value()) < time_stamp;
                        ^~~~~~~~
                        value

While this may be uncommon, it is a regression compared to when this would work, prior to the JFR import. The HotSpot build in 8u is supposed to be independent of the autoconf build and the JFR changes break this separation.

The fix is simply to use ifneq ($(ENABLE_JFR),true) instead of checking for false. This is already the case in the Windows build and this bug only affects the *nix side of the build.