## Description

Because we can't be sure that the API's set of utilities is 100%
comprehensive, or that its location-to-utilities mapping is 100%
correct, we should have an escape hatch, so users don't have to give
an answer they know is incorrect.

The "other" value is not submitted to the API because it's not a valid
utility ID and the API would thus error. I'm pretty confident that's
sensible behavior for the API, so I'd rather not change it. We'll be
able to tell when someone chose "other" in API logs, when (a) the
utility param is absent in the /calculator request, while (b) the zip
is in a launched state. Since it's hard to know if a zip is in a
launched state when you're just looking at API logs, we may want to
explicitly record zips submitted with an "other" utility somewhere; if
so, we can do that as a followup.

I'm not sure about this Spanish translation. It's "otra" (feminine)
because it's referring to the feminine noun "empresa" (company), which
is part of the translation of "electric utility". Anyone who knows
Spanish better than I do (i.e. most people), feel free to correct me.

https://app.asana.com/0/1206661332626418/1206700057950880

## Test Plan

On a fresh page load, make sure the utility dropdown is not
clickable.

Enter a zip in a launched state (02861); make sure utilities load, the
first one is selected, and the "Other" entry is present. Submit the
form with a real utility selected and make sure its incentives come
up. Choose "Other", submit the form, and make sure no utility
incentives come up, but state and federal ones do.

Enter a zip in a non-launched state (76104); make sure utilities load,
and "Other" is the only option.

Enter an invalid zip (00000) and make sure the utility dropdown is not
clickable and you see the error message below the field.