Validation options should be checked even if generateValidation is set to false

[alexander-yevsyukov]

Before version 2.0.0-SNAPSHOT.2 we used to have integration test data declared like shown below:

// A message with a value that has a malformed range.
message IllegalRanges {
    double value = 1 [(range) = "{0.6..4.2}"];
}

// A malformed range expression, the range is not closed (as in the right edge is omitted).
message UpToInfinity {

    int32 value = 1 [(range) = "[0.."];
}

// A malformed range expression, the range is unopened (as in the left edge is omitted).
message Unopened {
    int32 value = 1 [(range) = "..2)"];
}

message MinorCitizen {

    // Malformed range - the value the field is `int32` - whole number,
    // while the value of the left range edge is a floating point number.
    int32 age = 1 [(range) = "(0..18.01)"];
}

message Constitution {
    // This should break the compilation because `repeated` is missing.
    string amendments = 1 [(distinct) = true];
}

message Constitution {
    // This should break the compilation because `repeated` is missing.
    string amendments = 1 [(distinct) = true];
}

It was under the smoke-tests/validation sub-project. This project had generation of validation code turned off.
Because of this tests pass. Turning validation on via the following code...

modelCompiler {
    generateValidation = true
}

... rightfully breaks the compilation.

The problem is that it should break the compilation even if generation of the validation code is turned off, because we do not want to keep a malformed code. Delaying the discovery of compilation errors to a later date, when validation is wanted, is a bad idea.