Degree measures for digraph

[DoganCK]

Added degree measures and tests for digraph

Notes:

• Renamed distribution to sequence in the Degree module because degree distribution is a probability distribution whereas a degree sequence for a graph is defined as "non-increasing sequence of its vertex degrees". I left it as is for the FGraph for now @LibraChris not to break other things.
• I suppose we take the degree of a node in a directed graph to be the sum of its in- and out-degrees. Which I implemented in that fashion. However, it would be great if we could cite anything as there are edge cases for which there may not be a settled consensus. (e.g. how many times to count self-loops, once or twice? )
• I couldn't understand the division by 2 in NetworkDensity line 22: let potentialConnections = ((nodesCount) * (nodesCount-1.)) / 2. because for directed graphs possible non looping edge count is (nodesCount) * (nodesCount-1.), no?

[codecov[bot]]

Codecov Report

Merging #33 (3069963) into developer (f9c8554) will increase coverage by 2.49%. The diff coverage is 59.52%.

@@              Coverage Diff              @@
##           developer      #33      +/-   ##
=============================================
+ Coverage      25.31%   27.80%   +2.49%     
=============================================
  Files             28       28              
  Lines           1197     1212      +15     
=============================================
+ Hits             303      337      +34     
+ Misses           894      875      -19     

Files Changed	Coverage Δ
src/Graphoscope/Measures/Loop.fs	44.44% <0.00%> (-22.23%)	:arrow_down:
src/Graphoscope/Measures/OutDegree.fs	60.00% <53.84%> (+8.14%)	:arrow_up:
src/Graphoscope/Measures/Degree.fs	55.55% <66.66%> (+22.99%)	:arrow_up:
src/Graphoscope/Measures/InDegree.fs	74.28% <92.30%> (+22.43%)	:arrow_up:

... and 1 file with indirect coverage changes

[LibraChris]

Hey Thank you for implementing the degree and loop measures for DiGraph. In regards to your notes:

• I think this renaming is a good idea and I will rename the FGraph functions in accordance, but the ordering of the degrees in the sequence is not set in stone. In "The Atlas for the Aspiring Network Scientist" it is defined as being sorted "in descending degree, so you always start with the node with maximum degree and you go down until you reach the node with the lowest degree".
• Bollobás, B. (1998). Modern Graph Theory. Graduate Texts in Mathematics. https://doi.org/10.1007/978-1-4612-0619-4 states "a loop is taken to contribute 2 to the degree of a vertex", while the KONECT Project makes different degree definitions for different graph types. This is an important point for future discussions on source materials.
• In this you are correct, the definition for possible edges was for an undirected graph. Since FGraph can potentially be used for undirected graphs it was implemented as such, but it should be corrected.

The only thing we need to agree upon is to remove type conversions and, when possible, work with casts. This results in more performant code and the type conversion can be used on top of that if needed. This would mean working with Sequences operations instead of Array operations. This also results in the same type of return types between FGraph and DiGraph operations.

[DoganCK]

@LibraChris There are some places where it’s super sensible to use Enumerables but I’m not sure this holds all the time. Honestly, I need to dig deeper as to how they work under the hood as well. Let’s postpone discussing those to a later time.

Also the ordering of degree sequences from the atlas book seems effectively the same to me. non-increasing is a slightly more rigorous way of putting it than decreasing because there may be nodes with equal degrees.

[LibraChris]

Ok Let´s handle this at a later time