[mlir]: Clarify docs for external OpTrait::FunctionLike ops

[frej]

Summary

The documentation claims that an op with the trait FunctionLike has a
single region containing the blocks that corresponding to the body of
the function. It then goes on to say that the absence of a region
corresponds to an external function when, in fact, this is represented
by a single empty region. This patch changes the wording in the
documentation to match the implementation.

Signed-off-by: Frej Drejhammar <[e-mail]>
Co-authored-by: Frej Drejhammar <[e-mail]>
Co-authored-by: Klas Segeljakt <[e-mail]>

[frej]

@ftynse are you willing to do the commit as I don't have commit rights? I'd like the change to be attributed to "Frej Drejhammar <[e-mail]>" if possible.

mlir/docs/Traits.md

 *   `OpTrait::FunctionLike`
 
 This trait provides APIs for operations that behave like functions. In
 particular:
 
 -   Ops must be symbols, i.e. also have the `Symbol` trait;
 -   Ops have a single region with multiple blocks that corresponds to the body
     of the function;
--   the absence of a region corresponds to an external function;
+-   An op with a single empty region corresponds to an external function;
 -   arguments of the first block of the region are treated as function
     arguments;
 -   they can have argument and result attributes that are stored in dictionary
     attributes on the operation itself.
 
 This trait does *NOT* provide type support for the functions, meaning that
 concrete Ops must handle the type of the declared or defined function.
 `getTypeAttrName()` is a convenience function that returns the name of the

mlir/include/mlir/IR/FunctionSupport.h

 } // namespace impl
 
 namespace OpTrait {
 
 /// This trait provides APIs for Ops that behave like functions.  In particular:
 /// - Ops must be symbols, i.e. also have the `Symbol` trait;
 /// - Ops have a single region with multiple blocks that corresponds to the body
 ///   of the function;
-/// - the absence of a region corresponds to an external function;
+/// - An op with a single empty region corresponds to an external function;
 /// - leading arguments of the first block of the region are treated as function
 ///   arguments;
 /// - they can have argument attributes that are stored in a dictionary
 ///   attribute on the Op itself.
 /// This trait does *NOT* provide type support for the functions, meaning that
 /// concrete Ops must handle the type of the declared or defined function.
 /// `getTypeAttrName()` is a convenience function that returns the name of the
 /// attribute that can be used to store the function type, but the trait makes