Refactor: move procedure definitions to submodules

[rouson]

This PR demonstrates an example of separating procedure interface bodies (in a module) from procedure definitions (in a submodule). In current form, the PR applies this process only to what was originally named mod_random.

Benefits:

1. Reduces the information a user encounters when attempting to use a module.
2. Clarifies what parts of the module are part of the API. For example,
   • A procedure's local variables no longer appear in the module.
   • A non-public module entity (e.g., pi) no longer appears in the module.

This PR also proposes a new scheme for file, module, and submodule names:

• Prefix nf_ to reduce name clashes with other projects,
• Suffix _mod for modules, and
• Suffix _submod for submodules.

If approved, this PR can be updated to apply similar changes to the rest of the files in src/:

• mod_activation.f90
• mod_kinds.f90
• mod_mnist.f90
• mod_parallel.f90
• mod_io.f90
• mod_layer.f90
• mod_network.f90

[milancurcic]

Thanks a lot! Is it possible (allowed) to duplicate the interfaces in the submodule?

Let's keep renames in a separate PR. So this PR would address only submodules, and the other PR would do only renaming. Obviously you need a submodule naming convention in this PR. I think I prefer the more explicit "_submodule" suffix, I hope that's fine with you.

[milancurcic]

I found out recently that this "naive" implementation of normal distribution is not completely normal and is somewhat skewed toward lower values. It's probably not a big issue (training works as is), but should be fixed nevertheless. Could be a good opportunity to involve Fortran stdlib. Will open a separate issue for that.

[rouson]

@milancurcic thanks for reviewing this so quickly. Yes, it is possible to repeat the interface information in the submodule. I'm in a small minority of programmers who likes not repeating the information so I thought I'd try it this way just see if the change would survive scrutiny. :) The overwhelming majority of people whom I encounter prefer the repetition so your suggestion will reduce the frustration of other contributors. I'll make the changes you requested and then I'll proceed with the rest of the files.

[rouson]

@milancurcic your comments about the normal distribution are timely because I need to write a unit test for a distribution normality for another project. I'll try the tests out on your code.

Also, I pair-programmed this PR with a collaborator who commented that the formulas neural-fortran uses to generate normally distributed data has some problems in the tails. Apparently, the formulas in neural-fortran are fine for most applications so it's not necessarily a cause for concern -- just something to be aware of in case the issue crops up in some way.