…raph` (petgraph#863)

This PR continues the work done in PR petgraph#794. Thus, it resolves petgraph#542.

It adds `map_owned` and `filter_map_owned` methods for both `Graph` and
`StableGraph` which take ownership of the respective graphs and their
respective associated data in comparison to the `map` and `filter_map`
counterparts which only take `&` references.

Appropriate tests for this have been added. If desired, I can also add
quickchecks, but this did not seem necessary.

---------

Co-authored-by: Pete Hayes <[email protected]>

Allow the goal node to be dynamically and lazily evaluated.

This can be useful in graphs where testing whether a node is the goal is
costly (e.g. "a node is a goal if its hash is equal to a list of
possible values")

<!--
  -- Thanks for contributing to `petgraph`! 
  --
-- We require PR titles to follow the Conventional Commits
specification,
-- https://www.conventionalcommits.org/en/v1.0.0/. This helps us
generate
  -- changelogs and follow semantic versioning.
  --
  -- Start the PR title with one of the following:
  --  * `feat:` for new features
  --  * `fix:` for bug fixes
  --  * `refactor:` for code refactors
  --  * `docs:` for documentation changes
  --  * `test:` for test changes
  --  * `perf:` for performance improvements
  --  * `revert:` for reverting changes
  --  * `ci:` for CI/CD changes
-- * `chore:` for changes that don't fit in any of the above categories
  -- The last two categories will not be included in the changelog.
  --
-- If your PR includes a breaking change, please add a `!` after the
type
-- and include a `BREAKING CHANGE:` line in the body of the PR
describing
  -- the necessary changes for users to update their code.
  --
  -->

…ts (petgraph#865)

<!--
  -- Thanks for contributing to `petgraph`! 
  --
-- We require PR titles to follow the Conventional Commits
specification,
-- https://www.conventionalcommits.org/en/v1.0.0/. This helps us
generate
  -- changelogs and follow semantic versioning.
  --
  -- Start the PR title with one of the following:
  --  * `feat:` for new features
  --  * `fix:` for bug fixes
  --  * `refactor:` for code refactors
  --  * `docs:` for documentation changes
  --  * `test:` for test changes
  --  * `perf:` for performance improvements
  --  * `revert:` for reverting changes
  --  * `ci:` for CI/CD changes
-- * `chore:` for changes that don't fit in any of the above categories
  -- The last two categories will not be included in the changelog.
  --
-- If your PR includes a breaking change, please add a `!` after the
type
-- and include a `BREAKING CHANGE:` line in the body of the PR
describing
  -- the necessary changes for users to update their code.
  --
  -->

### Description

This pull request resolves petgraph#864.

1. **Fixes a bug in `all_simple_paths`**: The original implementation
could return a self-looping path when `from`=`to`, as described in the
issue.

2. **Adds `all_simple_paths_multi` for multiple targets**: A new
function, [`all_simple_paths_multi`](src/algo/simple_paths.rs:144), has
been implemented. This function finds all simple paths from a single
source node to a `HashSet` of possible target nodes, in a single DFS
traversal.

Unit tests have been added to validate the fix and to ensure the
correctness of the new multi-target pathfinding functionality across
various graph types and edge cases.

TODOs:
- [x] Add benchmarks to the functions in `src/algo/simple_paths.rs`
- [x] Add docstrings for the new `all_simple_path_multi` function.

Help needed: Finalise the design choice to exclude the single node path
when `source = target`

This PR cleans up the main directory of the repo. In particular it does
the following:
- Remove Makefile (The makefile is not in use anymore)
- Move image assets (with Logo) into separate folder in assets (for
greater clarity)
- Move graph-example to assets (for a better overview in the main
directory)
- Remove custom.css (as it is not in use anymore)

Please correct me if `custom.css` or `Makefile` are actually still in
use (e.g. in the release process) :)

…#871)

Closes petgraph#870

The `IntoEdges` implementation for `UnidirectedAdaptor` does not produce
the same set of edges references as an equivalently-constructed
undirected graph. This prevents search and traversal algorithms from
working if the traversal or search would require traversing an adapted
edge whose underlying directed edge is "incoming" (which would prevent
traversal in the directed case).

The underlying reason is that we currently, correctly concatenate
incoming and outgoing edges from the underlying directed graph but
they're concatenated with the same orientation which produces a set of
redundant `EdgeReferences`-- making the adapted graph equivalent to the
underlying directed graph as far as the `IntoEdges` implementation is
concerned.

The `IntoEdges` implementation for undirected graphs produces two
`EdgeReference`s for each graph edge-- one for each orientation. This is
what allows traversal of edges in either direction.

The solution is to make the `UndirectedAdaptor`'s `IntoEdges` behavior
match that of an undirected graph by reversing the edges with `Incoming`
orientation. That way there will be two `EdgeReferences` for each edge
as there are in undirected graphs.

<!--
  -- Thanks for contributing to `petgraph`! 
  --
-- We require PR titles to follow the Conventional Commits
specification,
-- https://www.conventionalcommits.org/en/v1.0.0/. This helps us
generate
  -- changelogs and follow semantic versioning.
  --
  -- Start the PR title with one of the following:
  --  * `feat:` for new features
  --  * `fix:` for bug fixes
  --  * `refactor:` for code refactors
  --  * `docs:` for documentation changes
  --  * `test:` for test changes
  --  * `perf:` for performance improvements
  --  * `revert:` for reverting changes
  --  * `ci:` for CI/CD changes
-- * `chore:` for changes that don't fit in any of the above categories
  -- The last two categories will not be included in the changelog.
  --
-- If your PR includes a breaking change, please add a `!` after the
type
-- and include a `BREAKING CHANGE:` line in the body of the PR
describing
  -- the necessary changes for users to update their code.
  --
  -->

---------

Co-authored-by: Paul Jakob Schroeder <[email protected]>

This will allow us to have finer control over the formatting process.

Fix: petgraph#194

<!--
  -- Thanks for contributing to `petgraph`! 
  --
-- We require PR titles to follow the Conventional Commits
specification,
-- https://www.conventionalcommits.org/en/v1.0.0/. This helps us
generate
  -- changelogs and follow semantic versioning.
  --
  -- Start the PR title with one of the following:
  --  * `feat:` for new features
  --  * `fix:` for bug fixes
  --  * `refactor:` for code refactors
  --  * `docs:` for documentation changes
  --  * `test:` for test changes
  --  * `perf:` for performance improvements
  --  * `revert:` for reverting changes
  --  * `ci:` for CI/CD changes
-- * `chore:` for changes that don't fit in any of the above categories
  -- The last two categories will not be included in the changelog.
  --
-- If your PR includes a breaking change, please add a `!` after the
type
-- and include a `BREAKING CHANGE:` line in the body of the PR
describing
  -- the necessary changes for users to update their code.
  --
  -->

Co-authored-by: Egor Starovoitov <[email protected]>

Currently, the best documentation for `Dot::with_attr_getters` is [this
comment](petgraph#194 (comment))
on issue petgraph#194.

This PR adds a doc comment to this constructor that discusses relevant
Config options, explains the argument types for the functions and where
to find more info about those types, and provides a small examplel

---------

Co-authored-by: Raoul Luqué <[email protected]>

## Brief
Add [bidirectional
Dijkstra's](https://en.wikipedia.org/wiki/Bidirectional_search)
algorithm for the shortest path between two points.
```rust
pub fn bidirectional_dijkstra<G, F, K>(
    graph: G,
    start: G::NodeId,
    goal: G::NodeId,
    mut edge_cost: F,
) -> Option<K>
where
    G: Visitable + IntoEdgesDirected,
    G::NodeId: Eq + Hash,
    F: FnMut(G::EdgeRef) -> K,
    K: Measure + Copy,
   ```

## About the algorithm and implementation
The time complexity of bi-directional dijkstra is the same as normal dijkstra. However, in certain scenarios (e.g. grids and sparse road networks), it has to explore significantly less nodes to find the shortest path. https://www.ucl.ac.uk/~ucahmto/math/2020/05/30/bidirectional-dijkstra.html is a great resource on the correctness of the algorithm.

## Benchmarks
Under the right circumstances (large & sparse networks), it clearly shows that bidirectional dijkstra is faster than normal dijkstra.
```
test dijkstra_bench_grid ... bench: 469,582.30 ns/iter (+/- 12,469.78)
test dijkstra_bench_grid_bidirectional ... bench: 47,145.54 ns/iter (+/-
1,139.01)
test dijkstra_bench_grid_with_target ... bench: 118,156.60 ns/iter (+/-
3,168.78)
```

However, the existing benchmark also shows that it's not always beneficial.
```
test dijkstra_bench_random ... bench: 745,014.06 ns/iter (+/- 22,892.76)
test dijkstra_bench_random_bidirectional ... bench: 1,556,466.68 ns/iter
(+/- 77,702.84)
test dijkstra_bench_random_with_target ... bench: 694,060.94 ns/iter
(+/- 18,275.15)
```

On macbook pro M1

---------

Co-authored-by: Raoul Luqué <[email protected]>