Refactoring for clearer API around the Analysis Lifecycle and support for pulling datatypes from server

[fmagin]

This PR introduces a clearer split between the 3 levels of guarantees about the relation between a local Ghidra Program and an analysis on the server (referenced by an AnalysisID):

1. There is no AnalysisID associated with the Program at all: Available actions are basically limited to starting an analysis.
2. An analysis on the server has been associated with the local Program. Either by creating a new analysis or associating an existing one. In this state there are no guarantees made about the state of the analysis. It might still be running, or it might have already failed with an error. Actions related to querying the status of an analysis require at least this.
3. A successfully finished analysis exist for the Program and the immutable FunctionIDs have been associated with the local functions in Ghidra. This is needed for the core product features like searching for matches, AI decomp.

Level 2 is guaranteed by obtaining a ProgramWithID object from the GhidraRevengService. The only method to obtain an instance of this class is GhidraRevengService#getKnownProgram(Program) which returns an Optional<ProgramWithID> that will only be non-empty if the Program is associated with an AnalysisID internally.

Level 3 is guaranteed by obtaining an AnalysedProgram from GhidraRevengService#getAnalysedProgram(Program)

Methods on the service now have type signatures that encode what they require, i.e. requesting the AI decompiled code requires a FunctionID and the only way to obtain a function ID is to query it from the AnalysedProgram instance. The caller thus has to obtain an AnalysedProgram first, forcing them to explicitly handle the case where an empty Optional is returned i.e. when no finished analysis is available for this Program. This also makes the error cases clearer: A FunctionID might not be available because the analysis didn't successfully finish, or it might not be available because the local (thunk) function does not have an associated FunctionID on the server side.

Additionally, this PR implements the feature to pull datatypes together with function names from the server, via a dedicated pull method. This method is designed to be called repeatedly and simply does nothing if no changes were found (and in this case does not even create an empty transaction).