Break up and remove `core/internal_constants.js` and `core/constants.js`

[cpcallen]

Background

#5140 is an important precursor to finishing the first pass of migrating goog.provides to goog.module by removing side effects from core/constants.js, which previously modified the Blockly object by adding a large number of assorted @constant properties to it.

In order not to advertise any new API surface, these constants have been redeclared in core/internal_constants.js (rather than core/contstants.js), which is marked @package to prevent their use outside of core.

Proposal

• All constants should be moved out of this file and to the file(s) containing the code to which they relate.
• Where they are only used in a single module, they should become unexported, module-local constants in that file.
• Consideration should be given as to whether they could be renamed to improve readability.
• Where they are intended to be user-configurable parameters:
  • They should be renamed so as not to be CONSTANT_CASE and, to comply with style guide rules forbidding mutable exports, and either be
    • moved to an exported options object, or
    • replaced with pairs of get/set functions that modify an unexported local variable.
  • The current alias in core/blockly.js should be replace by a getter/setter pair to provide backward compatibility.
• Groups of related constants should become a suitably named @enum where appropriate.

Specific recommendations

• OPPOSITE_TYPE should be moved to connection_type.js—and possibly also be renamed to make code that uses it is more readable—e.g., let x = oppositeConnectionType[y] instead of … = OPPOSITE_TYPE[y]. (There's no rule that requires objects that happen never to be mutated to be declared in CONSTANT_CASE.)
• …

[cpcallen]

Actually, come to think of it, we should probably also go over core/contstants.js and make sure that anything in it that has a more suitable home is moved, too.

[alschmiedt]

Ok I did some work on this but I am planning on putting it down for now. The current state of this is:

• constants.js are meant for values we expect developers to be able to use but not change. However, there are only two values in here so this might change depending on what happens to those values.
• config.js are meant for values that we expect developers to be able to use and to change
• Any value that should actually be an internal constant should go in a module it relates to or its own module. See sprites.js.

All the values in internal_constants that still need a new home:

• COLLAPSE_CHARS - I believe this is a contender for being passed into the options struct since we already have a collapse option and allowing a developer to specify how many characters to allow in the same spot makes sense to me. However, I held off since we don't really have a good set of rules on what should/should not go into the options struct.
• BUMP_DELAY & DRAG_STACK - Should either go in config.js or in the options struct. I couldn't decide which for similar reasons mentioned above.
• RENAME_VARIABLE_ID & DELETE_VARIABLE_ID - These are only used inside FieldVariable so I think they can be exported from there. I don't think they can be private since it is possible someone would want to use them when they extend FieldVariable.
• OPPOSITE_TYPE - See original PR comment.