Various tests are allow strings in JSON/JWT when numbers are required

The JSON library (com.google.gson) we use, and hence the Environment calls that wrap around it, will silently coalesce strings to numbers, e.g. in com.google.gson.JsonPrimitive getAsLong:

   public long getAsLong() {
        return this.isNumber() ? this.getAsNumber().longValue() : Long.parseLong(this.getAsString());
    }

This means that the following unit test for ValidateIdToken would fail if added - ie. the id_token is accepted as valid, when it is invalid as the exp claim is not a number.

	@Test(expected = ConditionError.class)
	public void testEvaluate_invalidExpString() {

		JsonElement o = claims.remove("exp");
		claims.addProperty("exp", o.getAsString()); // a string (containing a valid number) is not ok

		env.putObject("client", client);
		env.putObject("server", server);
		addIdToken(env, claims);

		cond.evaluate(env);

	}

Some of our tests already explicitly check 'isNumber' correctly, but many don't (as the above unit test failing shows).

We need to do a full check of the code for the bad pattern. I suggest we also change Environment.getLong() [and the other get primitives) to return null if the requested value is not already of the requested type.

(This was discovered via code inspection when I looked at ValidateIdToken after Stewart asked me a question about it.)