program: safe deserialize config keys from state

[buffalojoec]

Problem

Working with the Firedancer conformance suite revealed another relatively inconsequential control flow mismatch between the BPF version of the Config program and its original builtin version.

Similar to #16, when the BPF version of the Config program attempts to deserialize ConfigKeys - this time from account state - there can be mismatches on error codes due to BPF program panics due to memory allocations.

In the case of a malformed account with a large ShortU16 vector length, but not enough data for the provided length, if the length causes too large of an allocation, the BPF program will panic (OOM), rather than returning ProgramError::InvalidAccountData like the builtin does.

Again, similar to #16, this would still cause an error, but this change ensures maximum backwards compatibility. Furthermore, writes to a config account's ConfigKeys are shielded by the input buffer restrictions.

Summary of Changes

Add a check for the provided ShortU16 vector length to the program's config account state deserialization, to catch any invalid buffers and avoid OOM panics in favor of backwards-compatible error codes.

[joncinque]

Makes sense -- nice catch and fix!