docs: update outdated bloc documentation links on README (#190)

Fixes #189

README.md

@@ -311,7 +311,7 @@ in fact, some work very similar to or exactly the same across the libraries.
 Aside from the fact that bloc is just a heavy weight wrapper around the reducer pattern
 (which can be more elegantly done with `useReducer` from `flutter_hooks` or `use.reducer` in ReArch),
 bloc is designed in a manner that thwarts any form of useful composition
-and then [proceeds to blame that limitation on proper application design!](https://bloclibrary.dev/#/architecture?id=bloc-to-bloc-communication)
+and then [proceeds to blame that limitation on proper application design!](https://bloclibrary.dev/architecture/#bloc-to-bloc-communication)
 
 What is suggested there (as of December 2023) is arguably incorrect;
 proper application design should _encourage_ the use of composition,
@@ -320,7 +320,7 @@ Composition is a design pattern that has been known about for
 [many, many years](https://en.wikipedia.org/wiki/Design_Patterns)
 and can be achieved via dependency inversion (which the docs explicitly say _not_ to do).
 If you disagree with this assertion, let me counter with a question:
-why should you [jump to _UI code_ to connect pieces of _app layer state_](https://bloclibrary.dev/#/architecture?id=connecting-blocs-through-presentation)
+why should you [jump to _UI code_ to connect pieces of _app layer state_](https://bloclibrary.dev/architecture/#connecting-blocs-through-presentation)
 that naturally need to interact with each other?
 Such a suggestion is clearly a workaround as you are then putting app layer logic in your UI code,
 and consequently results in unmaintainability as your app states independently evolve over time.