Enterprise: Custom Builds: Rename some source code files to separate words with dashes

[EdwardCoyle]

Is your feature request related to a problem? Please describe.
This is an extension issue of #417. In order to fully automate custom builds, it's become necessary to create a hard guideline on matching a component's filename to its constructor. If the component is comprised of multiple words:

• each word is capitalized in its constructor
• each word is separated by a dash in the filename

For example, consider the following:

// `src/components/datepicker/datepicker.js`
// becomes...
// `src/components/date-picker/date-picker.js`
// to match...
function DatePicker(element, options) { 
  //...
}

// `src/components/contextualactionpanel/contextualactionpanel.js`
// becomes...
// `src/components/contextual-action-panel/contextual-action-panel.js`
// to match...
function ContextualActionPanel(element, options) { 
  //...
}

Describe the solution you'd like
Firstly, there are some parts in the new build script being developed in #417 that should be reversed. A hard list of filename keys to dash-separated filenames is present that's currently handling the conversion. This is working for now, but the idea is to fully automate custom builds so that the file structure handles the order of the component files inside the build.

Next, we need to rename the following files to match the structure suggested above:

• [ ] applicationmenu -> application-menu
• [ ] busyindicator -> busy-indicator
• [ ] circlepager -> circle-pager
• [ ] colorpicker -> color-picker
• [ ] compositeform -> composite-form (note that this is deprecated now https://github.com/infor-design/enterprise/issues/1944)
• [ ] contextualactionpanel -> contextual-action-panel
• [ ] datepicker -> date-picker
• [ ] emptymessage -> empty-message
• [ ] expandablearea -> expandable-area
• [ ] fileupload -> file-upload
• [ ] fileuploadadvanced -> file-upload-advanced
• [ ] listbuilder -> list-builder
• [ ] listfilter -> list-filter
• [ ] listview -> list-view
• [ ] monthview -> month-view
• [ ] multiselect -> multi-select
• [ ] popupmenu -> popup-menu
• [ ] searchfield -> search-field
• [ ] signin -> sign-in
• [ ] stepchart -> step-chart
• [ ] swaplist -> swap-list
• [ ] multitabs -> tabs-multi (change)
• [ ] timepicker -> time-picker
• [ ] toolbarsearchfield -> [DELETE] (shouldn't still be here)

In addition to renaming the files, we need to examine any internal import/export statements used on these files, and adjust them accordingly. We also need to allow the old nomenclature to access the new files (via mapping + dummy “function signatures”), but throw a deprecation warning during the build to notify the end user that these old names will not be accessible if they upgrade to the next major release (a future v5.0.0).

Finally, test the build with some custom parameters calling some of these out directly (and the pre-built bundles described in #427, if applicable), and make sure everything builds correctly.

[EdwardCoyle]

@tmcconechy @deep7102 do you guys have any objections to the naming convention I described?

[clepore]

As a note, we should definitely let LSF know about this change (and if we can think of anyone else)

[tmcconechy]

@duncsully @jake-harrington @awbuboltz
Heads up on this change so your aware in case it effects something in the build process as we rename some files..

[jake-harrington]

@clepore @tmcconechy Thanks for the heads up! We can probably handle changes like this fairly easily.

[tmcconechy]

Descoping this for now