Notecard reader driver

[DoomRater]

A system for reading notecards as pointed out by issue #55 would prove very useful at this point, since several enhancements would take advantage of loading notecards. All that would be needed is a way for master to understand what it is that needs reading, and the ability to return all of the requested data to the correct script via linked message. Limits that need to be kept in mind:
-sending too much data at once will cause scripts that are stripped for memory to crash when they receive the payload. We need to account for this and keep a certain byte payload in mind. I'd like to shoot for a total of up to 8 slave scripts at once, since the returned data from each slave script will be a maximum of 254 bytes. That's a maximum potential return payload of under 2048 bytes. If any script is below 2k we should look at rewriting it to have more free memory at some point.
-master may receive the link messages from notecards out of order. It will likely be master's responsibility to reorder the data accordingly when sending it back to the calling script.
-will master be able to handle multiple jobs at once? One possibility we might encounter is that two scripts want to utilize the master reader, and need to have the second job queued. And potentially more jobs queued. These need to be taken into account when attempting to use this as a general purpose solution.

[DoomRater]

Placing the notecard reader driver in another prim will reduce colliding slave messages with scripts that need to hear from master. Somewhere master needs to be able to flag the data it sends so that the correct script parses it while the rest ignore it rather quickly.

[DoomRater]

Although we can't glean any code from OpenCollar, we can derive a known fact about multi-object prims: if each prim holds a single script, we can fine tune which scripts are sent messages, This allows us to send much larger messages to scripts that can handle large amounts of data and keep it away from scripts that are strapped for memory. In addition, those parallel scripts aren't getting linked messages that need to be processed all the time as well.

The caveat is that the system becomes much less flexible for someone who wants to reuse DrizzleScript down the road to build a diaper of their own. They will have to attach multiple prims to their diaper just to get things working, and that messes with the ability to resize things. Thankfully avatars don't take a land impact hit when wearing multi prim objects.