Additional updates to docs links

Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>

docs/architecture/alternative-implementations.md

@@ -38,7 +38,7 @@ The general principle of an alternative implementation is:
 * Create a header file `xxx_alt.h` that defines the context type(s) used by the module. For example, `mbedtls_aes_context` for AES.
 * Implement all the functions from the module, i.e. the functions declared in `include/mbedtls/xxx.h`.
 
-See https://tls.mbed.org/kb/development/hw_acc_guidelines for a more detailed guide.
+See https://mbed-tls.readthedocs.io/en/latest/kb/development/hw_acc_guidelines for a more detailed guide.
 
 ### Constraints on context types
 

docs/architecture/testing/test-framework.md

@@ -6,7 +6,7 @@ This document is incomplete. You can help by expanding it.
 
 ## Unit tests
 
-See <https://tls.mbed.org/kb/development/test_suites>
+See <https://mbed-tls.readthedocs.io/en/latest/kb/development/test_suites>
 
 ### Unit test descriptions
 

docs/architecture/tls13-support.md

@@ -181,7 +181,7 @@ Coding rules checklist for TLS 1.3
 The following coding rules are aimed to be a checklist for TLS 1.3 upstreaming
 work to reduce review rounds and the number of comments in each round. They
 come along (do NOT replace) the project coding rules
-(https://tls.mbed.org/kb/development/mbedtls-coding-standards). They have been
+(https://mbed-tls.readthedocs.io/en/latest/kb/development/mbedtls-coding-standards). They have been
 established and discussed following the review of #4882 that was the
 PR upstreaming the first part of TLS 1.3 ClientHello writing code.