Fix option types in config backend

An issue was reported in SF2097. For background discussion, see MM chat. Briefly, we added new option type to OptionDataType enum. @piotrek added the new value close to the end, following advice in the comment. This enum happens to be used by config backend. As an effect, people who defined certain options in the CB on kea 2.4.0 (or earlier 2.5.x) and then migrated to 2.6.0 would end up with a broken configuration and Kea failing to start.

There are some workarounds known (1. @marcin proposed UPDATE dhcp4_option_def SET type = 18 WHERE type = 17;, 2. you can delete the option definition from the CB and define it in regular config).

It looks the following things should be covered:

• new schema version is needed. The upgrade script should be smart enough to determine if upgrading from a) 2.4.0 or earlier or b) from 2.6.0 and treat the option def data accordingly.
• the comment for OptionDataType should be corrected
• there are places in the code that does < logic on enums. That's not a good thing to do.
• (optionally) to be secured in the future, assign enum values manually to the last enum elements that should not be altered #3476 (comment 472329)
• (optionally) we should have a SQL table with enum values and foreign key in the option def tables referencing it.

This list is likely incomplete. Feel free to expand it.

The QA also have couple things to check here. This will be taken care in a separate ticket.