Fetch elevation in the backend instead of client

Description

Mobile client calls the elevation API (in services.ts) when we have a temporary location popover
Elevation is passed as a prop from the temporary location popover to the temporary location dashboard, and as part of the callback to each "create site" button
When a site is saved to the database, the elevation is saved along with it as site data
Viewing a site retrieves the elevation from the database

Whenever we need an elevation from mobile client, we check the client-side cache, and otherwise call a terraso-backend endpoint for elevation
Backend handles figuring out if we have elevation saved (for sites) or if we need to call the elevation API
Sites still have elevation saved as site data
Viewing a site still retrieves the elevation from the database

Seems more open to extension and less brittle -- if there end up being other entry points into site creation, that don't go through the TemporaryLocationCallout, the implementation is smoother
Having our own endpoint allows us more control -- we can introduce our own backend caching, rate limiting, etc. We have more control over what to do in the case of the API ever being down

User creates a site from a temporary location popover
User views a site after opening the app
User views a site after viewing the same site (caching still works)
User starts creating a site based on one lat/long, but changes the lat/long in the Create Site form
Sites that were created before elevation development happened are still able to display elevation now, or if the API is down upon site creation
Users of any permissions level can view elevation for a temporary location and relevant sites (Are there any other permissions considerations?)
(Nice-to-have) Not adding to our barriers for implementing offline experience