Add support for a custom "home" icon

[Etsija]

This PR adds a table for storing key-value pairs for UI configuration, and endpoints for getting, inserting and updating the stored configuration values. A minimal UI is implemented as the first use case of the table:

1. No entries in the configuration table of the database. The UI falls back to showing the "hardcoded" ORT Server favicon as the Home icon:

2. The admin has configured the Home icon by providing a valid URL to it, and toggling the showing of the tailored icon on:

3. The admin can still toggle between the tailored and hardcoded icons in the UI for comparison - this might be important later on, when we add support for more branding elements to the UI:

[mnonnenmacher]

This should return BadRequest instead.

[Etsija]

But the endpoint returns InternalServerError when a non-existing key is requested for, so I don't quite understand how I can force that behavior.

[mnonnenmacher]

This happens because enumValueOf<ConfigKey> below throws an exception when the key is invalid and you do not catch it, so the catch-all hanlder in StatusPages.kt in core turns it into an internal server error.
Instead, you should catch the exception and return a meaningful error response like so:

val keyParameter = call.requireParameter("key")
val key = runCatching { 
  enumValueOf<ConfigKey>(keyParameter)
}.getOrElse {
  call.respond(HttpStatusCode.BadRequest, ErrorResponse("Invalid config key $keyParameter.", "Allowed keys are: ..."))
  return@get
}

You could also throw an exception that is mapped to BadRequest in StatusPages.kt, but this global error handling does not play well with the idea that component should be self-contained.

[Etsija]

Trying to use ErrorResponse in the endpoint leads to a circular dependency warning, so I guess that will also break the self-containment requirement. Isn't core/api's ErrorResponse sitting in wrong location for the components to stay self-contained?

[Etsija]

I avoided the circular dependency problem by mapping the error response locally to a structure similar to the ErrorResponse class. Also verified that the error toast is rendered properly. While this isn't as elegant as using ErrorResponse directly for typing of the response, I hope it is sufficient for now.

[mnonnenmacher]

I would suggest to move ErrorResponse to :shared:ktor-utils but it can be done in a follow-up.

[mnonnenmacher]

This should return BadRequest instead.

[Etsija]

Same comment as before.