core module overview

// A path with . means that the . represents the original file name.

// During the discussion it came up to add a special sub-namespace seqan3::util for the utility module.

Strongly coupled with algorithms; so good for core
// rename to configuration
algorithm/configuration_element_debug_mode.hpp  -> core/configuration/configuration_element_debug_mode.hpp
algorithm/detail/... -> core/algorithm/detail/...
algorithm/algorithm_result_generator_range -> core/algorithm/algorithm_result_generator_range
algorithm/all.hpp
algorithm/bound.hpp -> Remove not used (also the seqan3::static_band in alignment module).
algorithm/concept.hpp -> core/configuration/detail/.
algorithm/configuration.hpp -> core/configuration/.
algorithm/configuration_element_debug_mode.hpp -> core/configuration/detail/.
algorithm/configuration_element_parallel_mode.hpp -> core/configuration/detail/.
algorithm/configuration_utility.hpp -> core/configuration/detail/.
algorithm/pipeable_config_element.hpp  -> core/configuration/. ? Should it be put into detail? Maybe we can add documentation for the pipe stuff for the config elements.

Utility
char_operations/all.hpp -> utility/char_operations/.
char_operations/predicate.hpp  -> utility/char_operations/. ~!has a dependency to alphabets (is_in_alphabet), when moved to alphabet module it must still be compatible with utility/char_operations!~ -> see: https://github.com/seqan/product_backlog/issues/262
char_operations/predicate_detail.hpp -> utility/char_operations/detail/predicate
char_operations/pretty_print.hpp -> utility/char_operations/detail/make_printable.hpp
char_operations/transform.hpp -> utility/char_operations/. (to_lower and to_upper)

concept/all.hpp
concept/cereal.hpp -> core/concept/cereal.hpp
concept/core_language.hpp -> utility/concept/.  ~? Are all concepts relevant - maybe exposition only concepts should not be exposed!~ see: https://github.com/seqan/product_backlog/issues/160#issuecomment-744393977
concept/tuple.hpp ->utility -> utility/tuple/concept.hpp

detail/all.hpp
detail/customisation_point.hpp -> core/detail/.

# current: // this might be 
#include <seqan3/alphabet/concept.hpp> // debug_stream
#include <seqan3/core/debug_stream.hpp>

# alternative: // it is closer to naming convention  
#include <seqan3/core/debug_stream/debug_stream_type.hpp> // additional, make  // predefined debug_stream
#include <seqan3/core/debug_stream/debug_stream.hpp> // -> debug_stream 
#include <seqan3/core/debug_stream/all.hpp> // optional, tuple, ... would fit to the current naming conventions.
// ! Marcel will work out a look and feel.
// Question: keep seqan3/core/debug_stream.hpp which adds all functionality, or
//           move this functionality to seqan3/core/debug_stream/all.hpp and keep 
//           seqan3/core/debug_stream/debug_stream.hpp separate.

// Refactor the debug_stream dependency to a customisation mechanism: @marehr is preparing some workpackages
detail/debug_stream_alphabet.hpp -> alphabet/detail/debug_stream_alphabet.hpp
detail/debug_stream_optional.hpp -> core/debug_stream/optional.hpp 
detail/debug_stream_range.hpp -> core/debug_stream/range.hpp 
detail/debug_stream_tuple.hpp -> core/debug_stream/tuple.hpp 
detail/debug_stream_type.hpp -> core/debug_stream/.  
detail/debug_stream_variant.hpp -> core/debug_stream/variant.hpp 

detail/empty_type.hpp  -> core/detail/.
detail/endian.hpp -> seqan3/std/bit
detail/int_types.hpp -> utility/detail/.  
detail/pack_algorithm.hpp -> utility/detail/. ?TODO: Maybe pack_traits/type_traits?
detail/strong_type.hpp -> core/detail/. ?TODO: it should be utility, but then it should be public. Also it depends on add_enum_bitwise_operators and debug_stream
detail/test_accessor.hpp -> core/detail/.
detail/to_string.hpp -> core/debug_stream/detail/to_string.hpp
detail/type_inspection.hpp -> utility/.

Where should this live: That probably should live in it's own module (together with contrib/parallel) and simd
// If strong_types gets into utility (what it seems it should), this should also go into utility.
// -> utility/simd/
// -> utility/parallel
// -> utility/offload

parallel/all.hpp -> utility/parallel/.
parallel/detail/all.hpp -> utility/parallel/detail/.
parallel/detail/latch.hpp -> utility/parallel/detail/.
parallel/detail/reader_writer_manager.hpp -> utility/parallel/detail/.
parallel/detail/spin_delay.hpp -> utility/parallel/detail/.
parallel/execution.hpp -> remove entirely

Where should this live: That probably should live in it's own module (together with contrib/parallel) and simd
simd/all.hpp -> utility/simd/.
simd/concept.hpp -> utility/simd/.
simd/debug_stream_simd.hpp -> utility/simd/detail/.
simd/detail/builtin_simd.hpp -> utility/simd/detail/.
simd/detail/default_simd_backend.hpp -> utility/simd/detail/.
simd/detail/default_simd_length.hpp -> utility/simd/detail/.
simd/detail/simd_algorithm_sse4.hpp -> utility/simd/detail/algorithm_sse4.hpp
simd/detail/simd_algorithm_avx2.hpp -> utility/simd/detail/algorithm_avx2.hpp
simd/detail/simd_algorithm_avx512.hpp -> utility/simd/detail/algorithm_avx512.hpp
simd/simd.hpp -> utility/simd/.
simd/simd_algorithm.hpp -> utility/simd/algorithm.hpp
simd/simd_traits.hpp -> utility/simd/traits.hpp
simd/view_iota_simd.hpp -> utility/simd/views/iota_simd.hpp; also rename the tests.
simd/view_to_simd.hpp -> utility/simd/views/to_simd.hpp; also rename the tests.

//TODO: This goes into utility but needs some exploration to see how it can be divided into list and pack entities
// Depending on this, we deferred the naming of the module and the sub-modules.
type_list/all.hpp -> 
type_list/algorithm.hpp -> metafunctions of type_list -> utility, public
type_list/traits.hpp -> ~!TODO: There is a cyclic dependency between pack_traits and list_traits.~ resolved see code!
type_list/type_list.hpp -> public, utility

// This should all go into utility.
type_traits/all.hpp -> utility/
type_traits/basic.hpp  -> utility/type_traits/. ~// TODO: What is really needed? And where should it actually be because basic seems to be an unfit name? Could we identify a similar naming scheme as cppreferenc does.~ -> seems resolved.
type_traits/concept.hpp -> utility/type_traits/. 
type_traits/deferred_crtp_base.hpp -> core/detail/.
type_traits/function.hpp -> utility/type_traits/function_traits.hpp ~!TODO: move multi_invocable out of header. Check multi_invocable with standard proposal.~ Done.
    -> utility/multi_invocable.hpp
type_traits/iterator.hpp -> core/detail/iterator_traits.hpp
type_traits/lazy.hpp -> utility/type_traits/lazy_conditional.hpp ~!TODO: move is_class_template_declarable_with to core.~ done.
type_traits/pack.hpp -> ~// TODO: replace by seqan3::pack_traits::contains -> old code used in alphabet_variant.~ done.
type_traits/pre.hpp -> core/type_traits/. 
type_traits/range.hpp -> core/range/type_traits.hpp ~//! range_compatible can be removed -> must be deprecated.~ done.
type_traits/template_inspection.hpp -> core/detail/template_inspection.hpp
type_traits/transformation_trait_or.hpp -> utility/type_traits/detail/transformation_trait_or.hpp

add_enum_bitwise_operators.hpp  -> core/add_enum_bitwise_operators.hpp , ~!TODO: Maybe better solution then one set of free-functions in one namespace.~ see: https://github.com/seqan/product_backlog/issues/260
all.hpp 
bit_manipulation.hpp -> utility/detail/to_little_endian and utility/detail/bits_of // remaining stuff goes into seqan3/std/bit
common_tuple.hpp -> core/tuple/. 
math.hpp -> utility/. 
debug_stream.hpp -> into debug_stream module, public, core // TODO depends on resolution above.
platform.hpp -> core
pod_tuple.hpp -> utility/tuple/., tuple, public
tuple_utility.hpp -> split into utility/tuple/split.hpp and utility/tuple/pop_front.hpp