Remove getModuleDependencies implementation

[weierophinney]

We're working on the Laminas Project migration tooling, and a user came across something today that we think may need to be addressed here.

SanSessionToolbar\Module defines getModuleDependencies(), and has it return a list including ZendDeveloperTools. When users perform a migration to Laminas packages, the equivalent package (laminas/laminas-developer-tools) is installed and activated in their application, but any attempt to run the application fails due to SanSessionToolbar indicating it requires the ZendDeveloperTools module.

The main reason to declare module dependencies predated heavy usage of Composer, and was a simple mechanism to ensure required dependencies were installed. In most cases, however, it is better to leverage Composer for this purpose.

The other reason to declare module dependencies was to ensure that listeners or services were available when the module performed bootstrap tasks. These scenarios can be achieved without usage of getModuleDependencies() in other ways:

• Listeners can always be registered, even if nothing ever triggers the events to which they listen.
• You can call $services->has() before attempting to pull a service, and abort if the service is not present.

In looking that the SanSessionToolbar\Module class, I see no reason for declaring the getModuleDependencies() method at all. The class does not work with any services or event emitters from the ZendDeveloperTools module at all, and all points of contact with that module are done via configuration.

My recommendation is to remove the method, which will help provide greatest forwards-compatibility.

[samsonasik]

@weierophinney thank you, I created PR #77 for it

[samsonasik]

implemented at #77