Adding keywords for Sunflower testing; Fixing Independent test running

1. Adding two new keywords - Register New User, Create A New Entry
2. Modifying keyword -Open browser to login page to accommodate all templates, Login to Eden with Arguments
3. Fixing the Independent test running aspect
3.1 Login, Logout removed from Start Testing and End Testing as the Login/Logout should depend on the use case.
3.2 Added Login, Logout to every testcase
3.3 Suite Setup, Suite Teardown added to every testsuite
3.4 Removed the unnecessary __init__.txt
My general advise is: stick with the case!

IMHO the story is "new user self-registers at the site". Not: "new user confirms his email address", nor "new user gets approved". So, what is required for the /user/ to successfully self-register, in any of those cases? 

As far as I know, the story goes:

- user enters user data
- user submits the registration form
- user gets redirected to the home page
- user sees a confirmation message

...where the confirmation message may differ between the three cases. 

The deployment settings may extend this story with:

- user can /not/ login until he has confirmed his email address (if email confirmation is required)
- user can /not/ login until his account has been approved

You could login as Admin afterwards and check whether the new user appears in the respective list and whether his registration is pending, because that's also an extension of that story:

- admin can see a list of pending registations

Approving a new user is a different story and hence a different test - and a different user (perspective). But possible: surely you can login as admin and approve a new user to test that? And then again login as the user to see whether you can login after approval? But not before approval! This is again part of the story:

- user can login after approval (if approval is required)
- user can login after email confirmation (if email confirmation required, and no approval required)

Similar, you could test email confirmation as a separate case, although that may be harder as you'd need to intercept the confirmation request (or fake one, which may be easier). But opening the URL in the confirmation email to see whether it succeeds makes for a nice test case.

So - stick with the case! Make sure you test the /requirements/ - and for that make clear the requirements to yourself. Try to tell the story as it really is.

Don't make the same stupid mistakes as in the old test suite.