Add CI job to verify that we have no broken links. (#50)

Fix all broken links.

book/src/04_traits/05_trait_bounds.md

@@ -166,7 +166,7 @@ Follow Rust's conventions though: use camel case for type parameter names.
 
 You may wonder why we need trait bounds at all. Can't the compiler infer the required traits from the function's body?  
 It could, but it won't.  
-The rationale is the same as for [explicit type annotations on function parameters](../02_basic_calculator/02_variables#function-arguments-are-variables): 
+The rationale is the same as for [explicit type annotations on function parameters](../02_basic_calculator/02_variables.md#function-arguments-are-variables): 
 each function signature is a contract between the caller and the callee, and the terms must be explicitly stated. 
 This allows for better error messages, better documentation, less unintentional breakages across versions, 
 and faster compilation times.

book/src/04_traits/08_sized.md

@@ -6,7 +6,7 @@ From our previous [discussion on memory layouts](../03_ticket_v1/10_references_i
 it would have been reasonable to expect `&str` to be represented as a single `usize` on
 the stack, a pointer. That's not the case though. `&str` stores some **metadata** next 
 to the pointer: the length of the slice it points to. Going back to the example from 
-[a previous section](06_str_slice):
+[a previous section](06_str_slice.md):
 
 ```rust
 let mut s = String::with_capacity(5);

book/src/04_traits/13_drop.md

@@ -1,6 +1,6 @@
 # The `Drop` trait
 
-When we introduced [destructors](../03_ticket_v1/11_destructor),
+When we introduced [destructors](../03_ticket_v1/11_destructor.md),
 we mentioned that the `drop` function:
 
 1. reclaims the memory occupied by the type (i.e. `std::mem::size_of` bytes)