Clarify style guidance for contributors and package authors (#57577)

- Deduplicate style guide in CONTRIBUTING.md and manual/style-guide.md
- Link from CONTRIBUTING.md to the manual
- Clarify contradictory function naming guidance

I took out the "Underscores are also used to indicate a combination of
concepts" language because I don't think that accurately reflects when
base uses snake case.

Author: LilithHafner

CONTRIBUTING.md

@@ -345,13 +345,11 @@ please remove the `backport-X.Y` tag from the originating pull request for the c
 
 #### General Formatting Guidelines for Julia code contributions
 
- - 4 spaces per indentation level, no tabs
+ - Follow the latest dev version of [Julia Style Guide](https://docs.julialang.org/en/v1/manual/style-guide/).
  - use whitespace to make the code more readable
  - no whitespace at the end of a line (trailing whitespace)
  - comments are good, especially when they explain the algorithm
  - try to adhere to a 92 character line length limit
- - use upper camel case convention for modules, type names
- - use lower case with underscores for method names
  - it is generally preferred to use ASCII operators and identifiers over
    Unicode equivalents whenever possible
  - in docstrings refer to the language as "Julia" and the executable as "`julia`"

doc/src/manual/style-guide.md

@@ -172,17 +172,19 @@ Counter-examples to this rule include [`NamedTuple`](@ref), [`RegexMatch`](@ref
 ## Use naming conventions consistent with Julia `base/`
 
   * modules and type names use capitalization and camel case: `module SparseArrays`, `struct UnitRange`.
-  * functions are lowercase ([`maximum`](@ref), [`convert`](@ref)) and, when readable, with multiple
-    words squashed together ([`isequal`](@ref), [`haskey`](@ref)). When necessary, use underscores
-    as word separators. Underscores are also used to indicate a combination of concepts ([`remotecall_fetch`](@ref)
-    as a more efficient implementation of `fetch(remotecall(...))`) or as modifiers.
+  * constants use all uppercase and underscores ([`LOAD_PATH`](@ref), [`VERSION`](@ref)).
+  * while anything not marked with `public` or `export` is considered internal, a prefix of
+    `_` also indicates that an object is not intended for public use.
   * functions mutating at least one of their arguments end in `!`.
   * conciseness is valued, but avoid abbreviation ([`indexin`](@ref) rather than `indxin`) as
     it becomes difficult to remember whether and how particular words are abbreviated.
 
 If a function name requires multiple words, consider whether it might represent more than one
 concept and might be better split into pieces.
 
+Function names should be written in snake case ([`minimum`](@ref), [`count_zeros`](@ref), [`escape_string`](@ref)).
+Base often breaks this convention by squashing words together ([`splitpath`](@ref), [`readeach`](@ref)) but this style is not recommended for packages.
+
 ## Write functions with argument ordering similar to Julia Base
 
 As a general rule, the Base library uses the following order of arguments to functions,