(cherry picked from commit 7c6c97b1e8bc9672e13c2da32eab91afd0d9c91d)

Conflicts:

	htdocs/theme/raw/templates/group/membersearchresults.tpl
	htdocs/theme/raw/templates/group/view.tpl

Moodle outcomes integration: view submission/release to/from mnet hosts; hidden view access keys; export of additional artefacts with views

NEEDS TESTING!!!

Blockinstance->allowed_in_view.

Fixed a couple of method calls in the meantime.

Again spotted by Heinz.

As pointed out by Heinz.

While I was doing that, internationalised the one for wall posts, and
refactored the generation of the help message to a function.

Institutions are strings, not numbers. Should've picked this up before.

copy_artefacts_allowed.

copy_artefacts_allowed is unnecessary as it's only called if the copy
type is 'full', and there's now no way that you would want to fully
copy a block and not copy the artefacts inside it.

Some other API tidyups have been done - default_artefact_config has been
renamed to rewrite_blockinstance_config and had a method signature
change to be a bit more flexible.

The copyconfig field of the View object is gone too, no longer required.

View.

This means that blog/profile/resume blocktypes don't show up in
group/institution/site Views.

This is controlled through a new Blocktype method - allowed_in_view.
Various code had to be changed to listen to this method, mostly around
the display of the category browser.

When making a template, all blocktypes are available.

Part 3 is to change the configuration forms to be more sensible when
editing a template, and then testing what happens when blocktypes are
rendered somewhere that they "shouldn't" be - e.g. a My Friends block in
a group View.

of 'user', to match the database schema.

[UPSTREAM] Prevent crashes relating to view feedback and complaints when javascript is not available.