Ensure rocks even if there are no plugins to install

[wbthomason]

Closes #524 by always checking if we need to ensure the installation of any rocks.

@nanotee I have not tested this at all yet, but I think this is (modulo some small bugfixes) what needs to happen to fix #524.

[nanotee]

Sorry for taking so long to get back to this. Gave this PR a go, still can't install rocks unfortunately. I think this is because the rocks table is a dict-like table, so getting the length with # always returns 0.

An idea I had to simplify code reuse is to make rocks a plugin type (like git and local). Do you think that would make sense as a long term goal?

[wbthomason]

Ah, you're right. I can fix that check to work properly.

re: better code reuse: I like that idea in principle, but it would require re-engineering a bit to change how we check if a given plugin is installed/not. Right now we batch the filesystem work for this for plugins, but if we treated rocks as a different kind of plugin we'd need to think about how to restructure. Otherwise, it fits nicely with the existing architecture for defining custom installers/updaters for plugins.

[wbthomason]

2eaff76 hypothetically fixes the check for rocks to install.

[nanotee]

Thanks for the quick fix. packer now detects that there are rocks to install, but it can't open the display window:

[packer.nvim] [ERROR 11:41:30] async.lua:20: Error in coroutine: ...e/nvim/site/pack/packer/start/packer.nvim/lua/packer.lua:414: attempt to index local 'display_win' (a nil value)

[wbthomason]

Whoops. This comes from a bad design decision in how packer opens its display. I'll see if I can figure out a workaround, or just bite the bullet and refactor.