Convenience functions and behavior modification of Folder object

After using h5pyd for a while, I'd like to propose a few new functions and changes to the Folder object. I believe these changes allow for more fluid file management programs and match the h5py syntax better.

### New functions/properties:

1. `Folder.create_subfolder(subfolder_name, **kwargs):`
- creates subfolder in the current folder. Returns new folder object. Raises error if current folder permissions do not permit writing.

2. `Folder.create_subdomain(subdomain_name, **kwargs):`
- creates subdomain in the current folder. Returns new domain object. Raises error if current folder permissions do not permit writing.

3. `Folder.load(local_filepath/filepaths, **kwargs):`
- loads local file to current domain. Basically calls h5pyd._apps.utillib.load_file to the current domain.

4. `Folder.subfolders:` => property
- returns a list of child folder objects

5. `Folder.subdomains:` => property
- returns a list of child domain/h5file objects

6. `Folder.subfolders:` => property
- returns a list of child folder objects

6. `Folder.info` => property
- returns what `Folder.__repr__()` is currently returning, i.e. dict of object information

### Changes to existing functions:

1. `Folder.__getitem__(path):`
- return object of item at the given path, e.g. a user with some folder object `x` could index into `x['path/to/my/data.h5']`

2. `Folder.__str__():`
- return either `Folder.domain` or `Folder.info`, not sure about this one.

3. `Folder.__repr__():`
- return `` to match standard h5py/p5pyd convention

4. `Folder.parent:` => property
- return parent object instead of parent domain

I can build a branch in my fork incorporating these changes along with general SOH updates like PEP8 compliance and standardized docstrings. Is there a specific docstring style that is preferred?

As for testing, should I continue to add lines into the three existing tests or would you prefer a more granular approach, i.e. a test case for each individual function? The current tests don't necessarily need to be removed, but I would think a more granular approach would highlight errors more clearly.