Altitude Angel Authentication/API Error in Latest Beta 1.3.77.1 Onwards

#### Issue details
**Altitude Angel Authentication/API Error in Latest Beta 1.3.77.1 Onwards**

I have done some testing with the new plugin version of Altitude Angel in 1.3.77.1 beta and although the basics (signin, map overlays etc.) are working, flight planning fails with an HTTP status code **"403 Forbidden"** upon arm (I tested with two different email accounts just to be sure .. one gmail and one outlook).

Therefore, I did some debugging in the latest source code (cloned from github yesterday) as well as the AA Guardian API docs (https://docs.altitudeangel.com/docs/conflict-resolution-service) and found that the problem seems to be because the **conflict resolution service** wants an **API key** for authentication **not the bearer token** that is used for other services such as the flight reports used previously prior to the AA refactor (https://docs.altitudeangel.com/docs/flightreports).

To confirm I signed up for an AA demo key and tested and it works when I replace the _.WithClient(Client)_ call with _.WithHeader("Authorization", "X-AA-ApiKey YOUR_API_KEY_HERE")_ as per the AA API docs in the Flurl call at line 294 in _AltitudeAngelClient.cs_

Anyway, this might be a licensing issue rather than a code issue, or there could be some other issue with the authentication that I missed, but I wanted to report since hopefully this can be resolved since the demo keys only last 28 days and thus are not an ongoing solution :)

That said, for my modest non commercial use, the original flight reports are fine and I was really just playing with it for fun, so am mainly reporting as an FYI!

Cheers,

casrya

#### Version
1.3.77.1 Beta onwards

#### Platform
[ ] All
[ ] AntennaTracker
[X] Copter
[ ] Plane
[ ] Rover
[ ] Sub

#### Airframe type
X4

#### Hardware type
_What autopilot hardware was used? (pixhawk, pixracer, PX4FMU etc)_
SITL

#### Logs
N/A tested in code/debugger

Read AltitudeAngelClient.cs around line 294 and compare the conflict resolution service authentication requirements with the existing Flurl call. Reproduce flight planning through arm using the reported beta context and determine whether the service requires an API key or another supported credential. Done means resolving the 403 without relying on a temporary demo key.

Written by the indexing model from the issue text.