docs: Mark rustdoc codeblocks as text

Author: volsa

src/lowering/polymorphism.rs

@@ -9,7 +9,7 @@
 //! # 1. Method calls within methods (and function block bodies)
 //! The reason we want to desugar all method calls within (other) methods is for the fact that a non
 //! overridden method may make use of an overridden method. For example consider
-//! ```
+//! ```text
 //! FUNCTION_BLOCK A
 //!     METHOD getName: STRING
 //!         getName := 'A';
@@ -54,7 +54,7 @@
 //! # 2. Method calls through a pointer variable pointing to a class or function block
 //! Essentially what is illustrated in 1. within the main function, consider:
 //!
-//! ```
+//! ```text
 //! FUNCTION main
 //!     VAR
 //!         name: STRING;
@@ -86,7 +86,7 @@
 //! issues. Compatible here refers to the fact that the order of the member fields must be constant. More
 //! specifically, the methods must be defined in "ancestral hierarchical order". To illustrate with the
 //! previous examples, assume we have
-//! ```
+//! ```text
 //! TYPE __vtable_A:
 //!     STRUCT
 //!         getName: __FPOINTER TO A.getName := ADR(A.getName);

src/lowering/vtable.rs

@@ -9,15 +9,15 @@
 //! # 1. Virtual Table POU Member Field
 //! Every root, i.e. non-extended, class or function block will receive a `__vtable: POINTER TO __VOID` member
 //! field. For example a function block such as
-//! ```norun
+//! ```text
 //! FUNCTION_BLOCK A
 //!     VAR
 //!         one: DINT;
 //!     END_VAR
 //! END_FUNCTION_BLOCK
 //! ```
 //! will internally expand to
-//! ```norun
+//! ```text
 //! FUNCTION_BLOCK A
 //!     VAR
 //!         __vtable: POINTER TO __VOID;
@@ -34,7 +34,7 @@
 //! methods `foo` (inherited) and `bar` (overridden) as well as `baz` (new). For these two function blocks we
 //! would generate the following virtual table structures:
 //!
-//! ```norun
+//! ```text
 //! TYPE __vtable_A:
 //!     STRUCT
 //!         foo: __FPOINTER TO A.foo := ADR(A.foo);
@@ -55,7 +55,7 @@
 //! The newly created `__vtable` member fields need to point to some instance of the corresponding virtual
 //! table. For that we will create one global variable for each virtual table. Deriving from the previous
 //! example we would generate the following two variables
-//! ```
+//! ```text
 //! VAR_GLOBAL
 //!     __vtable_instance_A: __vtable_A;
 //!     __vtable_instance_B: __vtable_B;