Parachains configurations nit comment (#8957)

# Description

I found the previous version of the comment for the
`schedule_config_update` function slightly unclear.

I understood it to mean that the application of two configuration
changes in the same session would lead to the change being applied in
the current session, instead of having to wait until the session change
as usual.

I tried this out on `chopsticks` just to be sure.

---------

Co-authored-by: Bastian Köcher <[email protected]>
Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Author: 3 people

polkadot/runtime/parachains/src/configuration.rs

@@ -1347,13 +1347,16 @@ impl<T: Config> Pallet<T> {
 	/// will check if the previous configuration was valid. If it was invalid, we proceed with
 	/// updating the configuration, giving a chance to recover from such a condition.
 	///
-	/// The actual configuration change take place after a couple of sessions have passed. In case
-	/// this function is called more than once in a session, then the pending configuration change
-	/// will be updated and the changes will be applied at once.
-	// NOTE: Explicitly tell rustc not to inline this because otherwise heuristics note the incoming
-	// closure making it's attractive to inline. However, in this case, we will end up with lots of
-	// duplicated code (making this function to show up in the top of heaviest functions) only for
-	// the sake of essentially avoiding an indirect call. Doesn't worth it.
+	/// The actual configuration change takes place after a couple of sessions have passed. In case
+	/// this function is called more than once in the same session, then the pending configuration
+	/// change will be updated.
+	/// In other words, all the configuration changes made in the same session will be folded
+	/// together in the order they were made, and only once the scheduled session is reached will
+	/// the final pending configuration be applied.
+	// NOTE: Explicitly tell rustc not to inline this, because otherwise heuristics note the
+	// incoming closure make it attractive to inline. However, in that case, we will end up with
+	// lots of duplicated code (making this function show up on top of the heaviest functions) only
+	// for the sake of essentially avoiding an indirect call. It is not worth it.
 	#[inline(never)]
 	pub(crate) fn schedule_config_update(
 		updater: impl FnOnce(&mut HostConfiguration<BlockNumberFor<T>>),