handle unknown lora region in config service gateway api

[jeffgrunewald]

This change is needed to handle gateways requesting region params when they do not have a valid or known default/fallback region set in their local settings.toml files when they make a request to the config service to get the current transmit parameters for their region.

The lookup/response from the config service will be prioritized as follows:

• If the gateway's pubkey/address is found on the current chain with an asserted location, that location will be mapped to a region and from there to region parameters and both will be returned to the gateway
• If the gateway supplies a valid lora region as its fallback and no gateway is found on-chain or the gateway is found to be not asserted the parameters for the fallback region supplied in the request will be returned to the gateway, along with the fallback region
• If the gateway's fallback region is not set or explicitly set to the new "Unknown" region, and no asserted region can be found, the "Unknown" region will be returned along with an empty parameters list

This change also changes the behavior of the API if the fallback region argument supplied in the gateway's request is not found to be a valid region. Where previously this would be converted to the enum default (first enum variant, us915) now it will return an "invalid argument" error to the client. For the purposes of this validation, the "unknown" region is considered a valid region.