docs: fix typo 'recieved' → 'received' in 3 files (#716)

The word 'received' was misspelled as 'recieved' in:
- en/services/offboard_control.md (line 8)
- en/services/parameter.md (line 144)
- en/services/component_metadata.md (line 134)

Author: ARYA-mgc

en/services/component_metadata.md

@@ -131,7 +131,7 @@ In summary:
 1. The component will ACK the command and immediately send the requested `COMPONENT_METADATA` message (populated with URI and CRC for the general metadata file).
    - A `CMD_ACK` of anything other than `MAV_RESULT_ACCEPTED` indicates the protocol is not supported (sequence completes).
 1. GCS waits for the `COMPONENT_METADATA` message
-   - If not recieved the GCS should resend the request (typically in the application level).
+   - If not received the GCS should resend the request (typically in the application level).
    - Once information is received:
      - the GCS checks if `COMPONENT_METADATA.file_crc` matches its cached CRC value.
        If so, there is no need to download the [general metadata file](#COMP_METADATA_TYPE_GENERAL) (or other files it references) as it has not changed since the last download.

en/services/offboard_control.md

@@ -5,7 +5,7 @@ The offboard control interface allows an external controller to send low-level a
 This is commonly used to provide external control of a real-time flight stack from a companion/mission computer, for example, in order to implement features such as obstacle avoidance or collision prevention.
 
 Generally setpoints are only obeyed in a specific flight-stack mode.
-The flight stack requires the setpoints to be recieved for some time before it will allow the mode to be enabled, and will switch out of the mode if setpoints are no longer received.
+The flight stack requires the setpoints to be received for some time before it will allow the mode to be enabled, and will switch out of the mode if setpoints are no longer received.
 
 The particular types of setpoints that are supported, if any, depend on the vehicle type and flight stack.
 

en/services/parameter.md

@@ -141,7 +141,7 @@ If working with a non-compliant component, the risk of problems when working wit
 
 A GCS (or other component) that wants to [cache parameters](#parameter_caching) with a component and keep them synchronised, should first get all parameters, and then track any new parameter changes by monitoring for `PARAM_VALUE` messages (updating their internal list appropriately).
 
-This works for the originator of a parameter change, which can resend the request if an expected `PARAM_VALUE` is not recieved.
+This works for the originator of a parameter change, which can resend the request if an expected `PARAM_VALUE` is not received.
 This approach may fail for components that did not originate the change, as they will not know about updates they do not receive (i.e. if messages are dropped).
 
 A component may mitigate this risk by, for example, sending the `PARAM_VALUE` multiple times after a parameter is changed.