Weather: Add v2 weather parsing in Weather App (forecast support)

[Rengyr]

This PR adds:

• Adjust code to unified and more modern javascript style
  • The main reasoning for fixing formatting of the code is that at first I thought I would fork the Weather App to a new one with forecast, but after discussion on GadgetBrige PR with weather data it was decided to keep it in the current Weather App. So I reused the code I had and tried to keep the improvements to readability.
• Split settings and weather data into two files in storage
  • It's cleaner this way to keep settings separate from weather data
• Add support for new version of weather data and forecast from GadgetBridge (requires version 0.86.0 or higher)
• Add support to automatically fetch weather at time interval defined in settings (requires GadgetBridge version 0.86.0 or higher)
• Add button to settings to force fetch weather data (requires GadgetBridge version 0.86.0 or higher)
• Add new API to get weather from Weather App for other Apps
  • This is described more in readme with examples

The forecast data are parsed only when requested by weather.getWeather(true) to minimize processing time used.

PS: I haven't tested it on BangleJS 1 and I haven't tested how it behaves with older version of GadgetBridge, but I don't see reason why it should break.

PSS: I wanted to add the support for forecast parsing/api separately, as I don't know how long it will take me to make the App to show the forecast data (mostly figuring out the design of it as there is not much screen space). However, with this change, someone else can make their own in the meantime or use the data for other purpose.

[Rengyr]

Thinking about the other weather PRs, there are two open things from my side.

1. With iOS support, we might want to conditionally show the settings based on what "weather provider" App is installed. Mostly to not confuse users with settings that won't do anything.
2. It's not used in this PR, but there are some extra data in the v2 even without forecast data and GB supports fetching only that. Extending the api shouldn't be an issue, just would be yet another settings item to fetch "extended data without forecast" or something.

[Rengyr]

I've added two things (both need the new GB).

• If we have at least extended version 2 data (even without forecast), it adds the "feels like temperature" to stored v1 weather. Still wouldn't rely that users will have the field, but can be used if it exists.
• Added to settings option to request extended data without forecast, maybe it will be useful for someone that wants extra weather data, but don't need the forecast (e.g. cloud cover, visibility, etc.).

Open points still are:

• Do we want to show all settings even if their installed weather provider (iOS in this case) can't support the settings (e.g. forecast)?
• I will rebase this PR to get rid of conflicts after all things are finalized, when we will be ready to merge it.

[RKBoss6]

I would say for all android or iOS specific settings, show only if the app is there 'ios integration, gadgetbridge integration.' That way it won't clutter up settings for an iOS user, and vice versa. I was thinking about integrating forecasts into weather for iOS, but that probably won't be right away.