Use behavior instead of behaviour

Follow up rubocop/rubocop@5b7c91b

.rubocop.yml

@@ -25,6 +25,9 @@ InternalAffairs/UndefinedConfig:
 
 Naming/InclusiveLanguage:
   FlaggedTerms:
+    behaviour:
+      Suggestions:
+        - behavior
     offence:
       Suggestions:
         - offense

docs/modules/ROOT/pages/cops_rails.adoc

@@ -2168,7 +2168,7 @@ Relying on instance variables makes it difficult to re-use helper
 methods.
 
 If it seems awkward to explicitly pass in each dependent
-variable, consider moving the behaviour elsewhere, for
+variable, consider moving the behavior elsewhere, for
 example to a model, decorator or presenter.
 
 Provided that a class inherits `ActionView::Helpers::FormBuilder`,
@@ -2856,7 +2856,7 @@ mixins on the filter, but these can confuse developers. If you specify
 methods that are defined in other classes or modules, you should
 define the filter in that class or module.
 
-If you rely on behaviour defined in the superclass actions, you must
+If you rely on behavior defined in the superclass actions, you must
 remember to invoke `super` in the subclass actions.
 
 === Examples
@@ -2922,7 +2922,7 @@ end
 class ArticlesController < ContentController
   before_action :load_article, only: [:update]
 
-  # the cop requires this method, but it relies on behaviour defined
+  # the cop requires this method, but it relies on behavior defined
   # in the superclass, so needs to invoke `super`
   def update
     super

legacy-docs/cops_rails.md

@@ -1030,7 +1030,7 @@ Relying on instance variables makes it difficult to re-use helper
 methods.
 
 If it seems awkward to explicitly pass in each dependent
-variable, consider moving the behaviour elsewhere, for
+variable, consider moving the behavior elsewhere, for
 example to a model, decorator or presenter.
 
 ### Examples
@@ -1379,7 +1379,7 @@ mixins on the filter, but these can confuse developers. If you specify
 methods that are defined in other classes or modules, you should
 define the filter in that class or module.
 
-If you rely on behaviour defined in the superclass actions, you must
+If you rely on behavior defined in the superclass actions, you must
 remember to invoke `super` in the subclass actions.
 
 ### Examples
@@ -1440,7 +1440,7 @@ end
 class ArticlesController < ContentController
   before_action :load_article, only: [:update]
 
-  # the cop requires this method, but it relies on behaviour defined
+  # the cop requires this method, but it relies on behavior defined
   # in the superclass, so needs to invoke `super`
   def update
     super

lib/rubocop/cop/rails/helper_instance_variable.rb

@@ -10,7 +10,7 @@ module Rails
       # methods.
       #
       # If it seems awkward to explicitly pass in each dependent
-      # variable, consider moving the behaviour elsewhere, for
+      # variable, consider moving the behavior elsewhere, for
       # example to a model, decorator or presenter.
       #
       # Provided that a class inherits `ActionView::Helpers::FormBuilder`,

lib/rubocop/cop/rails/lexically_scoped_action_filter.rb

@@ -12,7 +12,7 @@ module Rails
       #   methods that are defined in other classes or modules, you should
       #   define the filter in that class or module.
       #
-      #   If you rely on behaviour defined in the superclass actions, you must
+      #   If you rely on behavior defined in the superclass actions, you must
       #   remember to invoke `super` in the subclass actions.
       #
       # @example
@@ -71,7 +71,7 @@ module Rails
       #   class ArticlesController < ContentController
       #     before_action :load_article, only: [:update]
       #
-      #     # the cop requires this method, but it relies on behaviour defined
+      #     # the cop requires this method, but it relies on behavior defined
       #     # in the superclass, so needs to invoke `super`
       #     def update
       #       super