Consistently handle parsed enum values that are not listed in the enum
At the moment, Kaitai Struct doesn't consistently handle parsing of enum values that are not defined in the ksy. For example, with a spec like this:

```yaml
seq:
  - id: value
    type: u1
    enum: thing
enums:
  thing:
    0: zero
    1: one
    2: two
```

When parsing the byte array `[0x03]`, i. e. with the `value` field set to `3`, which is not listed in the `thing` enum, it's not clear what's supposed to happen. The documentation doesn't say anything about this case, and the behavior is inconsistent across target languages. Here's a summary of how each target language currently handles this case (I don't know all of these languages very well, please correct me if any of this is wrong):

* C++/STL, C#, Go: Unknown values are silently accepted and stored as the enum type. The generated parser directly casts the read integer value to the enum type, which these languages allow even if the value is not defined in the enum.
* Java, Lua: Unknown values are silently replaced with `null`/`nil`. Enum values are objects and can only represent values defined in the enum. KS-generated parsers look up an enum value matching the read integer value, and the lookup silently returns `null`/`nil` if there is no matching enum value,
* JavaScript, Perl, PHP: Enum values are stored as plain integers, so any value is accepted. KS-generated parsers represent enums as named constants (Perl, PHP) or bidirectional name/value maps (JavaScript), but they are not used when parsing enum values.
* Python with ksc 0.8, Nim: Unknown values cause an error when parsing. Enum values can only represent values defined in the enum.
* Python with ksc 0.9, Ruby: Unknown values are represented as plain integers. Enum values are objects (Python) or symbols (Ruby) and can only represent values defined in the enum. KS-generated parsers look up an enum value matching the read integer value, and if there is no matching enum value, the plain integer value is stored instead.
* Rust: Any value is accepted. KS-generated parsers apparently don't perform a proper enum lookup yet, so all values are represented as plain integers, even though the language has strong type checking for enums (I think).
* GraphViz, HTML: Doesn't matter - these targets don't actually parse anything.

In summary, most targets allow enum fields to have values that are not listed in the ksy, but some of the targets replace unknown values with `null`/`nil` or treat them as an error. I think it would make sense to change the behavior of the remaining target languages to allow unknown values as well.

The main problem with this is that unknown enum values are difficult to represent in languages like Java, which are strongly typed but don't have native support for something like strongly typed unions ("either" types) or case classes. Allowing unknown enum values would require defining/generating a custom wrapper class that can contain either a known enum object value or an unknown raw integer value, but this would make them less convenient to use in code that doesn't care about unknown enum values.

Related to #300 and #568, and somewhat related to #518.