implement mergeVariableStates!

[Affie]

I went back and forth on mergeVariableStates! and comparing it with updateVariableNodeData! and settled on following the verb by still providing a container. The same concept can be followed for all satellite levels (such as Blobentry)

@dehann would you mind giving your inputs.

[Affie]

I think variable should also be plural, so mergeVariablesStates! as mergeVariableStates merges on one variable.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.71%. Comparing base (1b6116f) to head (1f2adf8).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1145      +/-   ##
===========================================
+ Coverage    73.58%   73.71%   +0.12%     
===========================================
  Files           28       28              
  Lines         2442     2450       +8     
===========================================
+ Hits          1797     1806       +9     
+ Misses         645      644       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dehann]

I would have expected the default implementation signature to be

function mergeState!(<:Variable, <:VariableState)
  # actual implementation lives here
end

mergeState!(dfg::Factorgraph, lb::Symbol, state::VariableState) = mergeState!(getVariable(fg, lb), state)

mergeStates!(dfg::Factorgraph, ::Vector{<:Pair_}) = # pmap over vector mergeState!(dfg, pair[1], pair[2])

mergeVariableState!(w...;kw...) = mergeState!(w...;kw...) # alias

[Affie]

mergeState! is not consistent with the rest of the API as we have getVariableState and therefore would expect mergeVariableState!. We need the Variable noun in get explicit to avoid ambiguities, to have a type stable implementation in julia, and to help with SDKs without multiple dispatch. It also makes for more readable and maintainable code to be more explicit -- when updating from getSolverData, it was a pain to distinguish between Variable and Factor. We can still do the alias, but that would likely be a DFG only function and not across SDKs. I would also not include [get/add/merge/delete]State[!] for DFGv1 beta work.

Does the comment ... ::Vector{<:Pair_}) mean you are happy with the new signature, what I wanted to know form this PR?