doc: removed all references to old type_info class template

docs/md/core.md

@@ -302,7 +302,7 @@ These are the information made available by this object:
 * The name associated with a given type:
 
   ```cpp
-  auto name = entt::type_info<my_type>().name();
+  auto name = entt::type_id<my_type>().name();
   ```
 
   This is also an alias for the following:

docs/md/entity.md

@@ -803,8 +803,8 @@ std::unordered_map<entt::id_type, clone_fn_type *> clone_functions;
 
 // ...
 
-clone_functions[entt::type_info<position>::id()] = &clone<position>;
-clone_functions[entt::type_info<velocity>::id()] = &clone<velocity>;
+clone_functions[entt::type_hash<position>::value()] = &clone<position>;
+clone_functions[entt::type_hash<velocity>::value()] = &clone<velocity>;
 ```
 
 Stamping a registry becomes straightforward with such a mapping then:
@@ -865,8 +865,8 @@ std::unordered_map<entt::id_type, stamp_fn_type *> stamp_functions;
 
 // ...
 
-stamp_functions[entt::type_info<position>::id()] = &stamp<position>;
-stamp_functions[entt::type_info<velocity>::id()] = &stamp<velocity>;
+stamp_functions[entt::type_hash<position>::value()] = &stamp<position>;
+stamp_functions[entt::type_hash<velocity>::value()] = &stamp<velocity>;
 ```
 
 Then _stamp_ entities across different registries as:
@@ -1281,7 +1281,7 @@ thrown away. The reasons for this go far beyond the scope of this document.<br/>
 To iterate a runtime view, either use it in a range-for loop:
 
 ```cpp
-entt::id_type types[] = { entt::type_info<position>::id(), entt::type_info<velocity>::id() };
+entt::id_type types[] = { entt::type_hash<position>::value(), entt::type_hash<velocity>::value() };
 auto view = registry.runtime_view(std::cbegin(types), std::cend(types));
 
 for(auto entity: view) {
@@ -1299,7 +1299,7 @@ for(auto entity: view) {
 Or rely on the `each` member function to iterate entities:
 
 ```cpp
-entt::id_type types[] = { entt::type_info<position>::id(), entt::type_info<velocity>::id() };
+entt::id_type types[] = { entt::type_hash<position>::value(), entt::type_hash<velocity>::value() };
 
 registry.runtime_view(std::cbegin(types), std::cend(types)).each([](auto entity) {
     // ...
@@ -1310,8 +1310,8 @@ Performance are exactly the same in both cases.<br/>
 Filtering entities by components is also supported for this kind of views:
 
 ```cpp
-entt::id_type components[] = { entt::type_info<position>::id() };
-entt::id_type filter[] = { entt::type_info<velocity>::id() };
+entt::id_type components[] = { entt::type_hash<position>::value() };
+entt::id_type filter[] = { entt::type_hash<velocity>::value() };
 auto view = registry.runtime_view(std::cbegin(components), std::cend(components), std::cbegin(filter), std::cend(filter));
 ```
 

docs/md/lib.md

@@ -28,7 +28,7 @@ Many classes in `EnTT` make extensive use of type erasure for their purposes.
 This isn't a problem in itself (in fact, it's the basis of an API so convenient
 to use). However, a way is needed to recognize the objects whose type has been
 erased on the other side of a boundary.<br/>
-The `type_info` class template is how identifiers are generated and thus made
+The `type_hash` class template is how identifiers are generated and thus made
 available to the rest of the library. The `type_index` class template makes all
 types _indexable_ instead, so as to speed up the lookup.
 

docs/md/meta.md

@@ -280,7 +280,7 @@ auto by_type = entt::resolve<my_type>();
 auto by_id = entt::resolve_id("reflected_type"_hs);
 
 // lookup of a reflected type by type id
-auto by_type_id = entt::resolve_type(entt::type_info<my_type>::id());
+auto by_type_id = entt::resolve_type(entt::type_hash<my_type>::value());
 ```
 
 There exits also an overload of the `resolve` function to use to iterate all the